Ir para conteúdo
GPS Clube

Xamanian

VIP
  • Total de itens

    304
  • Registro em

  • Última visita

  • Dias Ganhos

    103

Tudo que Xamanian postou

  1. Amigo Wil, diMka Team = Xamanian, Sherlock e Plot. Abraços, .XA.
  2. Belias, todas as vezes que der erro de arquivo faltante você deve inserir o arquivo, tipicamente na pasta da resolução usada. No passado muitas pessoas modificavam certas skins e dava esse problema. Pegavam os arquivos de programação de uma e inseriam em outra, mas sem se darem conta que certos arquivos deveriam ir juntos também. Daí os erros em várias skins. Insira o arquivo faltante da mensagem de erro e faça testes. Pode ser que tenham outros. Insira todos até que a mensagem de erro desapareça. Abraços, .XA.
  3. Pessoal, tenho visto este tópico antigo sendo resgatado recentemente. Acho que as pessoas não entenderam como a coisa funciona. Explico: considere as seguinte linhas no sys.txt: [android] navigation_audio_stream = 4 ; or other num ;STREAM_VOICE_CALL - Value: 0 ;STREAM_SYSTEM - Value: 1 ;STREAM_RING - Value: 2 ;STREAM_MUSIC - Value: 3 ;STREAM_ALARM - Value: 4 ;STREAM_NOTIFICATION - Value: 5 ;STREAM_BLUETOOTH - Value: 6 ;STREAM_DTMF - Value: 8 Somente a primeira linha é efetiva, as demais não. Não adianta retirar o ponto e vírgula, pois são linhas sem ações. O melhor é fazer assim: [android] navigation_audio_stream=1 ;[Seleciona o tipo de transmissão de áudio: 0 = chamada de voz, 1 = sons do sistema, 2 = toques, 3 = música, 4 = alarmes, 5 = notificações, 6 = Bluetooth, 8 = DTMF]. A sigla DTMF significa Dual Tone Multi Frequency, que são os sons emitidos ao digitar as teclas. Em suma, na linha navigation_audio_stream=, após o sinal de igual, deve-se inserir um dos valores acima e fazer testes. Observe que usei o valor 1 como referência e é o que uso atualmente. Essa linha é para priorizar um dos canais de áudio, os demais não serão ignorados. A questão de música e voz não é tão simples assim, pois depende do projeto da central multimídia (CM). Já tive uma que abaixava o volume da música quando o GPS emitia um sinal de alerta (bipe ou voz). A atual corta a música quando o GPS dá alguma informação. Motivo: se há um alerta a ser informado, que nenhum outro som interfira na mensagem. É uma característica da CM e nada permite mudar isso. [ ]'s .XA. Na primeira linha deve-se inserir um valor (número) após o sinal de igual.
  4. Belias, está faltando um arquivo de nome diricon_YellowFlag25.bmp na skin do navegador. Pode estar faltando no data.zip (pasta 800_480 ou 480_272) ou está faltando na skin diMka (mesmas pastas). Observe que pode ter mais arquivos faltantes além de que foi apontado no erro. Solução: procure em outro pacote por um arquivo de mesmo nome e insira o arquivo no data.zip ou na skin diMka de seu pacote. O importante é usar arquivos de mesmo nome e da mesma resolução. Att, .XA.
  5. Obrigado pelas gentis palavras, nobre amigo Camelo Branco. Grande abraço, .XA.
  6. Amigo Facada, tendo a discordar da sua opinião sobre os arquivos HNR. Estes arquivos não estão relacionados com rotas entre países diferentes, mas sim em rotas consideradas grandes como, por exemplo, a partir de 100 km (mas essa distância é configurável no navegador GPS). Eles oferecem rotas otimizadas obtidas a partir de um banco de dados da própria Here, onde as rotas já foram testadas previamente. São rotas mais seguras, sem passar por estradas de chão e que oferecem um grande número de serviços para o condutor e passageiros (através de POI selecionados). Não são arquivos bobos e desprezíveis. Além disso, você disse que eles são disponibilizados nos pacotes para países da América Latina. Isso também não está correto. Os arquivos HNR são disponibilizados com os arquivos de mapas (FBL) para cada país individualmente, quando disponível (nem todo país tem HNR disponível). Em suma, os arquivos HNR fazem parte do pacote de conteúdo específico para cada país. Abraços, .XA.
  7. Bom dia, pessoal. O tópico é antigo, mas sempre aparece alguém com este mesmo tipo de problema. Deixo aqui uma solução que funciona sempre. 1) No arquivo sys.txt: Procure pelo parágrafo abaixo e deixe como informado: [GPS] port="auto" baud="auto" 2) Localize o seguinte arquivo: \save\profile\01\system.ini. Abra este arquivo e localize os seguintes parágrafos: [adaptive_routing_statistics] (se tiver; dependendo do navegador GPS, não tem) [config] [gps] Apague todas as linhas abaixo de cada um dos parágrafos informados acima e salve o arquivo. As demais linhas nos demais parágrafos deverão ser mantidas. Pronto! Sugiro também que as pessoas que disponibilizam pacotes façam o mesmo, deixando as configurações como informadas acima. Se assim não for feito, as configurações de localização, data, dados de satélites, etc. serão aquelas de quem montou o pacote. Isso implica em conflito em outros aparelhos, pois o navegador GPS vai tentar uma conexão que não dará certo. Apagando as linhas informadas no system.ini e deixando o sys.txt, como informado, deixa a conexão com satélites muito rápida. Esse é um dos grandes erros de quem monta pacotes, deixar de fazer essas configurações básicas antes de postar um link. [ ]'s .XA.
  8. Pessoal, aqueles que estão tendo problemas com conexão de satélites: façam o seguinte, entrem na pasta save/profiles/01 e localizem e abram o arquivo "system.ini". Localizem (está bem no começo) as seções [config] e [gps]. Apaguem todas as linhas abaixo de cada seção indicada (não mexam nas demais seções); salve o arquivo; volte com o cartão de memória para o dispositivo GPS. Feito isso, deixe o dispositivo em uma área aberta e espere pela conexão (pode demorar alguns minutos, já que os campos foram apagados). Este procedimento sempre funciona e pode ser usado quando o problema voltar. A lentidão da conexão ocorre após dias sem uso do GPS, pois ele tenta conectar nas coordenadas GPS informadas no system.ini, comparando com a última data informada. Claro, em dias nublados há maior dificuldade para obter sinal mais forte. Uma medida paliativa, quando demora mais tempo para conexão, é sair do navegador GPS e entrar novamente; isso pode ser feito umas duas ou três vezes (ou até mais); este procedimento força o navegador GPS a "limpar" as últimas informações e ir direto para o sinal dos satélites, sem ficar comparando com os dados do arquivo system.ini. Em dias nublados, onde o sinal é pior, esta prática de entrar e sair do navegador GPS pode ajudar em uma conexão com os satélites de maneira um pouco mais rápida. Att, .XA.
  9. Hufus, acho que a solução é simples, mas... Entre na subpasta \save\profiles\01 e localize o arquivo de nome "poi_visiblities.txt". Agora basta renomear a extensão (não é necessário apagá-lo, pois se não funcionar, basta voltar atrás): por exemplo, "poi_visiblities.t_t". Inicie o navegador GPS e faça testes. Att, .XA.
  10. Dias, este tipo de mensagem diz respeito a falta de arquivo(s) na skin ou no data.zip. "diricon" são os ícones de setas de direção que tipicamente aparecem no canto esquerdo superior, indicando qual direção deve ser seguida. Se você estiver usando uma skin diferente da skin padrão (que fica no data.zip), selecione outra skin e faça testes. .XA.
  11. Luiz Carlos, graças a Deus, não peguei! Feliz por você também, temos que evitar a todo custo, não é brincadeira! Não, as pastas são as comuns, por exemplo, a de mapas é só "map", sem as extensões como antes. Ou seja, o nome das pastas são como as originais. Idem para as demais, todas ficam com os nomes originais. Os arquivos da "map" ficam misturados, ou seja, os arquivos da TT e Here ficam nas correspondentes pastas. O módulo ux se encarrega de separar, mas aqui falo em separar arquivos da "map". Nas demais subpastas da content, há sobreposição de informações. Por exemplo, os POI da TT e da Here serão informados ao mesmo tempo, idem para building e demais. O módulo ux cria um botão que permite selecionar os arquivos do desenvolvedor. Caso seja usado apenas um pacote de desenvolvedor (por exemplo, só Here), então o botão fica como se estivesse desativado. Abração! .XA.
  12. Olá amigo Luiz Carlos! Você precisará de um módulo ux: [Hidden Content] Já no sys.txt você insere estas linhas: [mapchanger] map_ta=2020.06 map_nt=2021.Q2 onde map_ta é a versão do mapa atual da TomTom e map_nt é a versão do mapa da Here. Abraços, .XA.
  13. Amigo Cláudio, você está corretíssimo! Editei o meu post anterior, pois não havia observado que a seção citada era [warning.driveralert.settings], ou seja, uma seção específica para alertas de condução. Achei que o Xangai tinha perguntado sobre os comandos referentes às seções [warning] ou [speedcam_category:x], x = 0, ..., 31, que são para pontos de alerta (e até tem uns comandos parecidos também). Obrigado pela observação, meu caro, uma informação equivocada pode gerar muita confusão, por isso apaguei. Abraços!
  14. Editado: erro em resposta ao Xangai, não observei a seção [warning.driveralert.settings] e tudo o que escrevi foi um equivoco.
  15. Exatamente, amigo Atlan. Pense assim: uma espécie de cone (casquinha de sorvete) com o vértice localizado no dispositivo GPS e que vai se abrindo à frente e onde o ângulo da geratriz (uma reta com determinado ângulo, que ao ser girada forma a superfície deste cone) é dado pela linha citada por você. A coisa se dá em 3D, ou seja, não importa a altura que um ponto de alerta está localizado, mas que será captado se o mesmo estiver dentro da região cônica. Quando o ângulo é grande, pontos de alerta próximos serão captados. E o Primo/Nextgen não prioriza bem qual será o primeiro a ser informado. No caso do Primo, a última skin diMka permite ajustar a prioridade; melhora um pouco, mas não há milagres. Grande abraços!
  16. Amigo Atlan, anos atrás sofria com este problema e a solução está nos parâmetros apontados pelo Maurício, mas uso valores diferentes. São eles: [warning] speedcam_max_angle=40 speedcam_maxdistance_from_road=40 Estes são os melhores valores que testei até hoje e funcionam muito bem. Ângulo acima de 40 pode "pegar" pontos de alertas nas vizinhanças e ângulo muito baixo pode não avisar certos pontos de alertas, principalmente em ponto de alerta logo após a uma curva fechada. []'s .XA.
  17. Paulo e d780, este é um velho e conhecido problema. Ele está relacionado ao arquivo de fonema (extensão .ph) da TomTom. Ela produz dois tipos: LH+ e Sampa_UCL. Acho que o primeiro é o responsável. O segundo funciona, mas só em versões mais antigas, com o tempo também apresentou o problema com as vozes TTS. Sugiro remover tal arquivo da pasta Phoneme (antes, fazer um backup) e fazer testes. [ ]'s .XA.
  18. Hola Fabian, sim, você pode enviar os ícones. A minha sugestão é que você coloque um link com os ícones em arquivo compactado aqui neste tópico. Estou atualizando o branding novamente e nas próximas semanas irei divulgar neste tópico. Estou tendo pouco tempo em virtude do trabalho, mas estou pensando em fazer um tutorial básico referente à construção do branding; dá muito trabalho, mas não é difícil montar e atualizar o branding. Abraços, .XA.
  19. Juan, este branding é para Primo e Nextgen. Para usá-lo no iGO 8 ou no Amigo você terá refazer o arquivo de branding, mas é possível aproveitar os arquivos de imagem (bmp) que estão neste branding. Já o problema que você falou sobre o erro apontando o poi_brand.spr não é bem de resolução, mas sim de arquivo bmp configurado no spr e que não está sendo encontrado em seu navegador. Mas também pode ser a ausência deste arquivo spr, que tipicamente fica no data.zip. A maneira de resolver é abrir o data.zip e tentar localizá-lo, se não for localizado, então é necessário pegar de outro pacote e inserir no seu. .XA.
  20. Amigo d780, o alerta de voz que anuncia "semáforo" a partir do global_cfg é dado pelo arquivo config_database.lua que fica no arquivo de voz na pasta config. Ele é responsável pelas informações de manobras (vire à esquerda, em x metros, no próximo semáforo, etc.). E você tem razão, as informações sobre pistas e manobras são os ditos Alertas de Condução (drive alerts) que usam os ícones do global_cfg para alertas visuais e o arquivo de voz para os alertas sonoros. Não são pontos de alerta. Abraços, .XA.
  21. Amigos Jorge e Cláudio, a placa de "pista irregular" (Adverte ao condutor do veículo da existência, adiante, de um trecho de pista com superfície irregular) realmente existe: Por outro lado, teremos mais um ponto de alerta. Até hoje, aqui no nosso país, apenas o MapaRadar e o Fidelis se encarregam de cadastrar os pontos de alerta e a placa "pista irregular" não faz parte do banco de pontos de alerta de ambos. Ou seja, na prática ficaria se cadastro. Entendo que o caso "buracos na pista" é diferente, pois a minha intenção, ao fazer essa modificação em skin diMka para Primo, era que o próprio usuário pudesse inserir e remover estes pontos de alerta manualmente, independentemente do MapaRadar ou do Fidelis, uma vez que buracos surgem e são tampados com o tempo. Serve como alerta para não "cair" sobre os buracos; só isso. Já o "pista irregular", não, porém não sou contrário ao seu uso como ponto de alerta no Nextgen. Abraços, .XA.
  22. Jorge, Cláudio e demais colegas, o uso do ícone do cone foi introduzido por mim em skin diMka para Primo que modifiquei. Para isso usei o Type 24, que estava vazio até então e usei as seguintes linhas no lang e no voice: Hole in the ground="Buracos na pista" Hole in the ground,="Buracos na pista" Hole_in_the_ground="Buracos na pista" A minha ideia era usar este ponto de alerta (buracos na pista) para cadastrar eventuais buracos, mas de forma manual, inserindo este ponto de alerta pelo próprio Primo e excluindo quando tampados. Não pensei em criar um novo ponto de alerta para ser adotado pelo MapaRadar ou pelo Fidelis, já que buracos surgem e somem com o tempo, de modo que defendo que deve ser um alerta para o usuário administrar, pois entendo que isso é regional, ou seja, algo na região que a pessoa mais transita. Não tive motivo técnico para escolher o type 24, pode ser qualquer um, mas o uso do recurso e do ícone do cone me parece bem interessante e deveria ser mantido (não importando o type escolhido). Abraços aos amigo, .XA. EDIT: é preciso modificar o módulo ux para que o recurso seja habilitado (ou seja, tem que inserir as frases acima no módulo ux no lugar correto, além de modificar lang e voice).
  23. Amigo Jorge e demais colegas, concordo com as sugestões apresentadas pelo Jorge para modelos de ícones no padrão BR. Acho que estamos no caminho certo para deixar o Nextgen com um visual mais natural, exibindo placas e indicadores que encontramos diariamente nas ruas e rodovias. Vai ficar muito bom! Abraços a todos, .XA.
  24. Amigo Jorge, vamos lá! 1. Câmera no semáforo: a ordem dos primeiros ícones (Primo) é a seguinte: Type 1: Speed Camera (Radar fixo) Type 2: Built-in Speed Camera (Radar no semáforo) Type 4: Red light camera (Câmera no semáforo) Type 3: Average speed camera (Câmera de velocidade média) Type 1: Mobile speed camera (Radar móvel) (...) Type 11: Red light and speed camera (Semáforo com radar) Note que os ícones para o Type 2 e 11 são iguais. Motivo: o Type 2 não é usado aqui no Brasil, mas deveria. Por algum tipo de erro no passado, optou-se por usar o Type 11 para descrever "semáforo com radar". No lang eu mantive esta tradução, mas observe que ela está errada! O correto seria, em termos modernos, escrever "radar inteligente" no Type 11, uma vez que a tradução literal seria "semáforo com câmera e radar". Semáforos que detectam excesso de velocidade, cruzamento de veículos após fechamento (vermelho) ou parada do mesmo sobre faixa de pedestres são atualmente ditos radares inteligentes (por detectarem várias infrações). Note também que os ícones dos Types 2 e 11 têm uma câmera ao lado do símbolo do semáforo (deveria ter um radar e uma câmera no Type 11). O Type 4 (também usado no Brasil, corretamente, pelo MapaRadar) só tem um semáforo (terceiro ícones no print que postei antes), mas deveria ter uma câmera ao lado do mesmo. Pensei em mudar isso anos atrás, estes ícones "confusos", mas optei por deixar assim, pois já havia um entendimento do significado de cada um. Mas gosto da ideia de inserir uma câmera no ícone do Type 4 (que pode ser o mesmo para o Type 2 ou 11) e usar um ícone de radar sobre a figura do semáforo (tipo o ícone do Type 1, reduzindo o tamanho e colando o mesmo no ícone). Já o Type 11 (que usamos no país) deveria ter a figura do semáforo (gosto deste que uso) com uma câmera e um radar (ambos do mesmo lado, um acima e outro abaixo), pois daria real significado (radar inteligente). 2. Radar móvel: usei uma figura já consagrada no país, mas não é um padrão BR. Apenas inseri um pequeno radar na viatura. Mas gosto do ícone que citou, o tripé é mais real. 3. Pedágio e Polícia rodoviária: você tem total razão, os ícones estão fora do padrão, pois não existe placa padrão para estas duas categorias. No caso da placa para pedágio, peguei um ícone retratando uma cabine de cobrança de pedágio e inseri sobre um fundo que simula uma placa sinalização de indicação (placa azul e branco). Já para o ícone de polícia rodoviária, preferi usar um ícone consagrado no país desde o iGO8, que é o logotipo oficial da polícia rodoviária federal. Por outro lado, aqui no Brasil nós tratamos os pontos de alerta ditos "polícia rodoviária" os postos de policiamento federal e estadual. Mas não modifiquei algo que já estava consagrado e bem entendido pelos usuários de navegadores GPS. Baixei os ícones do nosso amigo Alain, vou ver depois; obrigado aos dois amigos. Abraços grandes, .XA.
  25. Amigo Jorge, a imagem abaixo contém os ícones que eu e o Adinis fizemos para o Primo e que uso até hoje. Essa é a minha sugestão de ícones para o Nextgen. Os arquivos de imagem (png) do tipo camerakSMSS_XX enviados anteriormente contêm todos estes ícones e podem ser usados caso haja concordância dos membros deste fórum interessados nos ícones no padrão BR. No caso do Primo, os arquivos camerak são usados nos menus e no blink (alerta visual na tela de navegação). Já os ícones das placas que aparecem na tela de navegação são aqueles que ficam no arquivo speedwarnXX.bmp (na skin ou no data). No caso do Nextgen, os ícones dos menus ficam na subpasta \res\nodpi (e são vetoriais, svg). Caso as demais subpastas da pasta \res não contenham ícones, então os arquivos da subpasta nodpi também serão usados na tela de navegação. Fiz testes no passado usando arquivos speedwarnX.bmp (X = 0, 1) nas demais subpastas da pasta \res e funcionou muito bem, mas eles só aparecem na tela de navegação (claro, não precisa ser bmp, o formato svg também funciona nestas subpastas). O problema está com os ícones da subpasta nodpi (só aceita svg mesmo). Estes ícones são usados na tela capturada que você postou acima, dois prints. Como defendo ícones diferentes para menus e tela de navegação, sugiro que se use ícones planos (como na figura acima) na pasta nodpi e ícones contendo as placas sobre "pezinhos" (simulando um pequeno poste) nas demais subpastas da pasta \res. Visualmente fica muito melhor. Abraços, .XA.
×
×
  • Criar Novo...