rafael2san

.

Quem gera esta tela da proxima manobra em 2D é um arquivo UX, um arquivo que adiciona funções extras ao navegador. Salvo a skin modificada pelo Zico que incorporou esta função (e não me parece o seu caso), para os demais usuários o nome do arquivo responsável é next_maneuver_overview_20.zip. Voce pode desativá-lo pelo menu em Configurações --> Configurações de orientação visual --> "Proxima manobra em 2d" ou "2D-overview of maneuver" (a tradução pode variar um pouco, depende do pacote que vc esta utilizando). Como é um add on, esta opção será uma das ultimas deste menu. Uma outra forma de desativar é deletando o arquivo, que estará dentro da pasta UX do seu navegador. Abraços

O NextGen com a skin pongo possui esta função alerts_only, ou seja, aviso por voz apenas dos alertas, sem a narrativa da rota traçada. É util em viagens onde o trajeto já é conhecido pelo usuário e apenas o acompanhamento visual das estatísiticas da viagem (distância, tempo restante, etc) é suficiente. Habilite o botão de controle do volume para ficar visivel no menu lateral da navegação (lado direito da tela) que ao ser pressionado alterna entre as seguintes funções: volume ligado / volume desligado / apenas o alertas. Neste último fica um ponto de exclamação no botão. Abraços

Não sei qual pacote estás utilizando, porém vozes para o NextGen Android tem suas peculiaridades. Normalmente o navegador utiliza 3 tipos de vozes diferentes: uma tipo com síntese de voz do próprio aparelho, e dois com mecanismo próprio. Vc pode verificar dentro do seu navegador, em configurações - configurações regionais - idioma da voz. 1. Vozes tipo naturais (não tts) são vozes tipo som analógico (como MP3, rádio, etc). Ou seja, o canal do volume e sua intensidade será o do próprio aparelho. Em outras palavras, o volume delas será o mesmo setado para MP3, rádio, etc. Geralmente as primeiras do menu de Idioma da voz (no navegador) são deste tipo. São vozes gravadas e por isso usam este canal e obviamente não leem os nomes das ruas. Se ao selecioná-lá nada é pronunciado talvez a central não libere o canal para este tipo em específico (vozes gravadas), ou o volume para "gps" está desativado nas configurações de som do aparelho 2. Há também vozes sintéticas, tipo tts, que geralmente é a voz do próprio dispositivo/aparelho. Ou seja, o navegador fornece o texto a ser lido para que a central o faça. O mecanismo de conversão de texto em voz do aparelho vai ler o que o navegador está enviando para ele. Por isso o nome das ruas são pronunciados. Este mecanismo é o mesmo utilizado para a leitura de textos para deficientes visuais, por exemplo. Então, o volume/liberação do audio quem dita é este mecanismo instalado do aparelho. Veja nas configurações do android, em idioma e entrada/voz, se o volume do mecanismo instalado no seu aparelho não está muito baixo. Provavelmente está ativo o do próprio aparelho, ou o mecanismo de síntese de voz do Google. Se nenhum está instalado, vc pode tentar instalar o do google (via loja do google), ou a Nuance. Claro, vai depender se seu pacote está habilitado para utilizá-los. Se ao selecioná-la nada é pronunciado pode ser devido à nenhum mecanismo de síntese de voz estar instalado. Normalmente este tipo de voz nem fica visível se um mecanismo não estiver instalado, mas isto não é regra. 3. Ainda, existem vozes tipo tts que não são dependentes do mecanismo instalado no dispositivo (como as tipo 2), Elas possuem mecanismo próprio de síntese de voz. Parecidas com as tipo 1, porém com mecanismo autônomo, com engine sintética própria, com regras de volume/liberação de audio idênticas ao tipo 1. Se este for seu problema, verifica cada um destes pontos e boa sorte! Abraços

Sua central chinesa possui versão do Android acima da 7? Se sim, o driver de vídeo do Oreo (em diante, salvo algumas exceções) é diferente dos anteriores. Somente desenvolvendo uma nova engine - compatível - para o velho Primo funcionar. O resultado é a tela preta, impossível de se renderizar, porém funcionando "por trás". Se este for o seu caso a solução é usar o Nextgen. Está bem desenvolvido 😉 Abraços

Apagando as linhas no customized.lua apenas retirou a variável da barra inferior, e nao é o correto pois o posicionamento dos itens na tela são levados em consideração. Olhando as (ótimas) modificações feitas pelo ziko, vejo que ele estabeleceu o comportamento: sem rota tem-se a barra de informações na direita, padrão diMka; e com rota, a skin assume a barra de informações no rodapé da tela. Quem comanda este comportamento é um observador. A primeira coisa que deve-se fazer é desativá-lo, retirando a linha em observers.ui: <observer value=(%navigation.has_route == 0) onselect={%lua.barrainferior=0} start="NO_TRIGGER"> Pronto. A linha acima está dizendo que quando não houver rota, não haverá barra no rodapé. Porém um outro observador, que dispara outra função, força a ativação da barra quando há rota. Devemos retirar esta imposição na função, e nao neste outro observador, pois a função comanda a contagem de pontos intermediários da barra. Para isso deve-se retirar em customized.lua, na função sc_wptContagem(): if MODEL.route.list.navigated.waypoints.list.size() > 2 then MODEL.lua.barrainferior = 2 else MODEL.lua.barrainferior = 1 end Após estas modificações, a barra não aparecerá mais, porém todo o código ainda estará na skin e não é bom deixá-lo lá ocupando espaço. Então, para aproveitá-lo, ativaremos a opção com barra e sem barra, deixando a critério do usuário a livre escolha. Então, voltamos com a variável que liga e desliga a barra em customized.lua: -- Barra inferior padrão ou estendida: st_EasyNav:useLayers(primary, "ui_barrainferior") MODEL.SETPERSISTENT.lua.barrainferior = INT_MODEL(0) e adicionamos o botão que permite a livre escolha em variable.ui, na userlist lmVGButtons: <row text="Barra de estatísticas inferior" icon="ico_statistics_mid.bmp#3" onrelease={if (%lua.barrainferior < 2) {%lua.barrainferior+=1} else {%lua.barrainferior = 0}} model=((%lua.barrainferior == 1 && %lua.barrainferiorUseLearningEta) ? "Padrão com \nLearning eta" : ((%lua.barrainferior == 2 && %lua.barrainferiorUseLearningEta) ? "Estendida com \nLearning eta" : (%lua.barrainferior == 1 ? "Padrão" : (%lua.barrainferior == 2 ? "Estendida" : "Off")))) type="_sldicon"> Pronto. Edição correta concluída. Provavelmente os bugs constatados por você não mais ocorrerão, afinal, a condição que posiciona os ícones estará "ligada" ou "desligada" corretamente. Abraços

O WinRAR 3.93 (qualquer versão antiga até a 4) só é totalmente compatível com as versões do Windows 10 até 1909. Para versões superiores do Windows, por exemplo 2004, 20H2, 20H2v2... o WinRAR 3.93 trava ao salvar um segundo arquivo editado (sem fechar e abrir novamente). Para editar apenas um arquivo não ocorre o erro. Por exemplo: se vc possui uma versão do Windows 10 atualizada (2004, 20H2, 20H2v2...), basta abrir um arquivo zip com o WinRAR 3.93, editar algum arquivo (UI ou lua por exemplo), salvar, e com o arquivo ainda aberto, editar outro arquivo e salvar novamente. O WinRar trava neste segundo salvamento e a alteração não é feita. Nem mesmo sair do WinRAR é possível. Sabemos que há outras formas de alterar arquivos do iGO, até direto pelo Windows (retirando e recolocando diretamente), mas com o WinRAR é muito mais fácil. Preferi fazer o downgrade (e cessar as atualizações do Windows) do que parar de usá-lo. Pelo menos por enquanto.😃 Abraços

jorgeultra, parabéns pelo empenho. Baixei agora para verificar, e tenho algumas sugestões que acredito que ajudarão. Pode-se usar o arquivo speedcam.zip original do pongo, e aplicar as modificações apenas nos arquivos "mod". Isto irá facilitar para você quando novas versões da skin forem lançadas. Podemos liberar o type 5 e 15 originais do speedcam.zip, diretamente no speedcam_mod_mods.ui do arquivo mod, assim: <!DISABLE COMPAT_UPCASE_ATTR_SELECTOR/> <modify lm_extendedSpeedCamList> <remove element="row[text=Multi Function Camera]"/> <remove element="row[text=Congestion Charge Zone]"/> <remove element="row[text=Speed Breaker]"/> <remove element="row[text=Dangerous Area]"/> E então adicionar suas modificações. Sugiro também trocar o SC camera para Violent Area (type 30), claro, ajustando lang e voice: <insert> <row text="Protected overtaking extra lane right side" tts="Protected overtaking extra lane right side ahead." id=15/> <row text="Give Way" tts="Give Way ahead." id=16 overspeedAlertDistance=0 speedcamOverspeedTolerance=0> <row text="Fixed Mobile Camera" tts="Fixed Mobile Camera ahead." id=17> <row text="Speed Breaker" tts="Speed Breaker ahead." id=18 overspeedAlertDistance=0 speedcamOverspeedTolerance=0> <row text="Children" tts="Children ahead." id=19> <row text="Dangerous Turn" tts="Dangerous Turn ahead." id=20> <row text="Tunnel" tts="Tunnel ahead." id=21> <row text="POI" tts="POI ahead." id=22 overspeedAlertDistance=0 speedcamOverspeedTolerance=0> <row text="RPS Post" tts="RPS Post ahead." id=23> <row text="Uneven road" tts="Uneven road ahead." id=24 overspeedAlertDistance=0 speedcamOverspeedTolerance=0/> <row text="Pedestrian crossing" tts="Pedestrians ahead." id=29> <row text="Violent Area" tts="Violent area ahead." id=30> <row text="Dangerous Area" tts="Dangerous area ahead." id=31> <row text="Max Height" tts="Max Height ahead." id=5 overspeedAlertDistance=0 speedcamOverspeedTolerance=0> </insert> Estes types devem ser inseridos/ajustados no plugin.ini do mod também. Ah, e minha ultima sugestão: a skin divide no menu o que é camera/radar e os que são os demais tipos de alertas. A linha abaixo define o que é radar/camera, ficando mais organizado: <modify SpeedcamTypes><modify element="field" speedcams=0,1,2,3,4,7,11,17,23/></modify> Dessa forma o speedcam.zip original não precisa ser modificado. Abraços

antoniok, não creio que esta seja a melhor solução. Imagina a quantidade de pontos duplicados! Os pontos de cada usuário teriam de ser depurados, otimizados e compilados em uma nova base. Um trabalho enorme. Há radares no MapaRadar os quais no momento do cadastro é incluído a data de verificação do INMETRO, com validade de 1 ano (se não me engano). Após exatamente um ano este ponto já pode ser excluído da base. Significa dizer que no outro dia o ponto já não será alertado, voltando ao "desconforto" e receio de usar tal base (infelizmente). Será que exatamente um ano após o vencimento este radar torna-se inativo, ou as multas que registrar serão automaticamente excluídas? Claro, compreendo que uma multa após este prazo é passível de contestação, pois a validade já havia expirado, e tudo mais. Será que todos recorrem? Duvido muito. Qual seria a interpretação da maioria dos usuários? 1. "Ah, com certeza este é um ponto não validado pelo INMETRO!" ou 2. "O Maparadar não é mais o mesmo, mais um radar que não alertou"? Complicado. Penso que uma mudança de critério seja o ideal. Talvez separarem estes pontos em outro banco de dados, e ao exportar a base, o usuário poderia escolher se deseja incluir estes pontos ainda não validados. Uma espécie de "limbo" de radares, permanecendo lá até a solicitação de exclusão por não estar mais ali fisicamente, ou reativado - se validado. Não quero provocar polêmica, longe disso. Analiso como uma preocupação mesmo. É muito triste perder a confiança em um serviço (gratuito) tão honesto, grandioso e colaborativo. Abraços

Concordo com você. Se é característica do site, respeita-se. No entanto, a base era tão confiável - e continua sendo (até mais agora), mas a falta desses pontos gera certo "desconforto" ao passar pelo radar. Fica a dúvida: "será que o radar que passei (e não fui alertado) ainda não está homologado (e conto com isso para não me preocupar), ou simplesmente ainda não está cadastrado da base?". Na minha opinião este comportamento é perigoso e acaba afetando - por rebote - a credibilidade do MapaRadar, já que muitos erros de interpretação surgirão. Sem contar que as atualizações dos radares tornam-se necessárias quase que diárias. Na dúvida, o usuário acaba não entrando no site para ajustar um ponto faltante, pois "ainda" confia no trabalho realizado e acredita que o ponto não deva estar homologado pelo INMETRO, e por isso não está cadastrado. É notável que o MapaRadar não é "simpático" com quem usa iGO, mas fico pensando que para a maioria dos usuários daquele site (inclusive os que pagam pelo app MapaRadar), até compreenderem toda esta informação e política, muita confiança pode ser afetada. Posso estar errado, mas notei que recentemente muitos radares têm sido cadastrados com a informação no tópico "AINDA NÃO VALIDADO PELO INMETRO". Torço para que não seja casualidade, e sim mudança de visão. Abraços

Também notei este comportamento no ultimo release do pongo. O problema esta unicamente no arquivo speedcam.zip. O primeiro bug que encontrei foi não alertar por voz natural, somente bipe, num primeiro alerta. O segundo foi a perda de alguns alertas da base (no meu caso: radares fixos e pedágios) conhecidos, mesmo estando corretamente cadastrados. Os parâmetros configuração estão ok. Estes erros não ocorrem com o speedcam.zip da versão 22.05.2020. O pongo já está ciente. Abraços

mauricioea, segue: https://ufile.io/83coktrb

Ziko, olhando o post do d780 - além de outros - em relação à falta da bmp ao trocar de skin, lembrei-me de como contornei na Ultimate SE: 1. A função abaixo verifica se o bmp da imagem está presente e retorna verdadeiro ou falso: -- 5) Verifica BMP em skin anterior à SE (Rafael2san): sc_IsExistBMP = function(BMP) if MODEL.EXITS.BMP then return true else return false end end 2. A partir disso, basta adicionar a chamada (sc_IsExistBMP) no template que busca a imagem, para verificar. Se falso (pois busca a imagem ainda na skin anterior), coloca a original. Em Windows CE a verificação em apenas uma imagem é suficiente (para Android, não). Para a mod ZK, basta ajustar a sintaxe abaixo: .btn_main_np.topleft { bmp:(sc_IsExistBMP("button_topleft_nopress_"+%lua.UltimateBtnType+".bmp#3") ? (%lua.UltimateBtnType ? ("button_topleft_nopress_"+%lua.UltimateBtnType+".bmp#3") : "button_topleft_nopress.bmp#3") : "button_topleft_nopress.bmp#3"); } Abraços

Legal hctomio, o processo de exportação até que não é o limite. Obrigado pela dica, estou engatinhando em OSM O Fidelis está associando as concessionárias aos pontos, com o viés que os nomes devem ser padronizados, o que nem sempre acontece. Enviou-me a Overpass API para baixar os pedágios por Estado, o que associado à concessionária facilita bastante. O que toma muito tempo mesmo é a atualização ponto a ponto. Mas de posse de uma planilha padronizada/otimizada talvez seja possível atualizar rapidamente pelo site, tornando o processo viável. Abraços

.