Xamanian

Atlan, não, não retirei os arquivos. Esta é uma de minhas revoltas e que expressei em um fórum amigo. Para "promover" algo está sendo feita uma campanha de denúncias sobre outro algo. Mais, (ainda) não posso falar. Entenda-me. Segue o link de ontem: https://nofile.io/f/vkARukfoG7t/Para+novos+testes.rar Outra coisa: hoje notei que a scheme Fast Ultimate (modo noite) tem um erro (meu), daí um travamento por falta de arquivo. Em seus testes, retire esta scheme. Aliás, use apenas aquelas do link acima. Tudo está sendo revisado e novo pack sairá quando for possível, mas espero que em breve (assim como as skins, no tópico devido). Em geral, as pessoas fazem questão de baixar coisas novas, mas não usam ou não testam. O que você está fazendo (testar e reportar problemas) é essencial, pois uma só pessoa não consegue fazer isso sozinho. Meus agradecimentos formais. Abração!

Caro amigo Atlan temos contato há tanto tempo a ponto de dizer que nos conhecemos sem nos conhecermos (encontrarmos para um bom papo)... Gosto desse lance neste mundo virtual... Pois então, talvez existam alguns problemas sim, não técnicos (no sentido de defeito), mas de configurações. Cada pacote tem suas peculiaridades, de modo que um ou outro arquivo pode ou não estar presente em determinado lugar. Este é o problema. Dou um exemplo, vou citar apenas duas linhas do arquivo color.ini (que fica dentro do zip das schemes): [icon] car="gfx/day/daycar.spr" flags="small_flags.spr" A primeira linha diz para o navegador procurar o arquivo daycar.spr no interior da pasta (externa ou interna) gfx/day. Já a segunda linha nada é dito. Quando isso acontece (nada é informado), o navegador procura os dados em dois lugares (no fundo no mesmo lugar, pois é descompactado no mesmo endereço): ou dentro da scheme ou dentro da skin (seja no data.zip ou em qualquer skin externa, como uma diMka). Quando um spr não é encontrado, então aparece uma mensagem de arquivo faltante e o navegador é desligado/encerrado. Quando o respectivo bmp não é encontrado, o aparelho reinicia. A rigor, o data.zip do Primo, bem como algumas skins, tem estes arquivos em seu interior e, portanto, não deveria dar problemas. Mas algo ou alguém pode retirá-lo por descuido de modo que... Não dá para ter controle. A parte mais polêmica nas schemes está neste campo: Todos os arquivos do campos/linhas do tipo "cursor" (menos dois "_big", que é para Amigo e iGO8) devem estar presentes no data.zip ou nas skins, caso contrário haverá travamento. Verifique, caro Atlan, se está usando algum data.zip sem estes arquivos, pois poderei lhe enviar para inserir no mesmo (mas preciso saber a resolução). Sim, sei, as minhas skins já tem algum tempo que postei, mas atualmente todas tem estes arquivos (e vou repostá-las em breve). Assim, acredito que não seja problema de seu navegador (o SW), pois este, ao que me recordo, tem todos os arquivos necessários (mas vai que algum deles ficou de fora). Outra coisa que é importante: o default.vis é problemático, ele exige mudança na pasta Save. Para não ter que apagá-la por completo, sugiro que apague apenas os arquivos internos (todos de extensão .prl, ou todos mesmo) da subpasta \save\preloads. Se não resolver, faça um backup de toda a Save, apague-a e reconfigure tudo. Não há motivos para não funcionar. Por fim, lembro que tive problema de travamento no dia de ontem e que relatei no tópico dos novos conteúdos da Here Q3: tinha arquivo corrompido, mas já corrigidos. Não sei se este é o seu caso, mas compensa analisar. Assim sendo, veja se há travamentos com as novas schemes/gfx/default.vis com o mapa da TT, se não existe, mas sim com novos conteúdos da Here, então suspeite dos conteúdos novos. Continue com seus testes e me mantenha informado. Mesmo que atualize os arquivos em breve (e assim o farei), é bom um retorno para saber como andam as experiências por aí. Abração!

Cláudio, hoje fiz testes com as schemes e o default.vis do arquivo abaixo: http://www35.zippyshare.com/v/VaWUEOTt/file.html Não tive travamentos, as superfícies artificiais apareceram corretamente. Não pude testar o zoom ainda (e também não troquei o dayheightcolormap.bmp). Parece que nomes de praças, shoppings realmente não aparecem, apesar de eu ter tentado algo no default.vis (este que lhe envio). Parece que o Amigo não reconhece, mas pode ser que as configurações estejam em outro arquivo. Não sei como capturar tela fora da tela de navegação, por isso não estou postando figuras. Usei a minha pasta GFX, porém tive que inserir os arquivos cursor.bmp e cursor.spr nas subpastas \gfx\day e \gfx\night. Caso queira testar, faça o mesmo (ou acusará falta de arquivo). Caso não queira fazer assim, basta mudar os caminhos do cursor no color.ini das duas cores (dia e noite) nestas schemes que seguem. Acho que com este default.vis a coisa muda no Amigo. Tá ficando bonito! hehehe Abraços!

Cláudio, na boa, jamais pensaria que o problema estava no dayheightcolormap.bmp, pois no Primo e NextGen este arquivo é usado apenas para sombreamento e elevação. Mas você está correto, ele trabalha com camadas, onde cada pixel (tipicamente ele tem só um 1 pixel de altura, mas é possível encontrar alguns com 2 ou 3), da esquerda para a direita, representa um nível de altitude. A rigor, o primeiro pixel mais a esquerda representaria o nível zero de altitude, ou seja, realmente o nível do mar. Mas no post acima onde explico os parâmetros do color.ini, divididos em três blocos (texture_id RGB e perfil de sombreamento/preenchimento), o valor 1 significa que o dayheightcolormap.bmp será usado e a cor RGB ignorada. É muito comum usar o valor 1 em "áreas verdes", mas que quiser setar um cor para cada categoria terá que usar o valor 0 ou 2. Pois bem, olhando o default.vis original do Amigo, bem com suas schemes (originais e modificadas por mim), pude ver que o oceano (e major_lake) está setado com o valor 2 e não 1. Portanto não faz sentido usar o arquivo de elevação. Preciso investigar mais o funcionamento do Amigo, realmente ele me surpreende (positivamente). Por fim, achei o tom de azul muito forte, sugiro um tom um pouco mais claro, o suficiente para diferenciar do tom azul usado em rios e águas menos profundas. Abraços!

Cláudio, estamos avançando... Veja, pelo que pude notar você não usou o arquivo default.vis que modifiquei. Hoje, mais cedo, fiz alguns testes, depois tive que sair e só retornei há pouco. Fiz o seguinte: usei as duas schemes que lhe passei, bem como a minha pasta GFX (que ficou na raiz do Amigo) e inseri o meu default.vis na pasta Amigo\ui_igo_easy\common (isto é, fora do data.gro). E fui testar. O Amigo carrega normalmente, mas está apresentando um problema, ele reinicia ao traçar uma rota mais longa. A questão é que descobri também que o Primo que uso aqui está apresentando o mesmo problema e ainda não consegui descobrir o motivo (não ocorre com qualquer rota). Verifiquei a pasta GFX, voltei para uma skin mais antiga (pois modifiquei dias atrás), mexi nas schemes que eu havia indicado no pack para serem colocadas na ui_igo9, mas nada. Estão deve ser algum problema nas schemes (estou fazendo modificações, provavelmente introduzi algum erro, mas vou descobrir o que é). Bem, ao que parece este meu default.vis funciona com o Amigo também, pois o erro que estou encontrando é idêntico ao que ocorre no meu pacote Primo. Mas ainda não posso afirmar isso. Peço que faça este teste com o default.vis aí também. Se surgirem os erros que lhe falei, deixe o parágrafo [icon] do color.ini idêntico àquele que você usa em sua scheme original (e que eu modifiquei). A questão da cor amarela é justamente as configurações no default.vis, que no Amigo estão erradas. Bem, não é erro, mas sim configurações indevidas. No default.vis para Primo e NextGen, todas as categorias de "água" estão setadas no default.vis com "sweet_water", ou seja, todas ficarão com a mesma cor definida no color.ini. Mas ainda não pude ver como estão no Amigo e iGO9. Esta cor amarelo claro que está aparecendo em suas figuras parecem idênticas aquelas que setei nas variáveis (no color.ini) beach_or_dune, recreational_area_ground e sand_area. Olhei rapidamente o default.vis original do Amigo e ele não seta estas variáveis. Não faz sentido aparecer esta cor no mar, mas na dúvida sugiro que você modifique uma por uma para ver se é o que eu falei. Dá uma radicalizada, use um vermelho (RGB 255,0,0) e veja se uma destas três altera a cor amarela (originalmente setei o valor RGB 245,245,200). Mas pode ser outra coisa ainda... Veja a textura que você usa em sua scheme e que foi mantida por mim: Post acima eu escrevi: Obs.: os valores para o identificador da textura (texture_id) são: 0 = construções 1 = áreas arborizadas em cidades 2 = áreas industriais, pistas de aeroportos, vias férreas 3 = florestas 4 = parques 5 = cemitérios 6 = águas 7 = áreas ferroviárias 8 = áreas urbanas 9 = fundo/solo No Amigo e iGO8 as texturas são usadas caso o arquivo seja do tipo acima; no Primo e NextGen o arquivo de textura é um bmp de 1x1 px e com transparência, ou seja, está só para evitar reset por falta de arquivo. Pode ser que sua scheme esteja usando este arquivo de textura. Por exemplo, ao que deveria estar setado para água (texture_id = 6), pode estar setado como solo (valor 9). Mas vou fazer mais testes no Amigo para ver como ele se comporta com estas cores. Quanto a parte dos labels, isto está no default.vis na parte que começa (no do Amigo) assim: ---------------------------- ROAD NAMES ---------------------------- ; LABEL VISUAL SETTINGS ; [Label<from>-<to>]: group name defines zoom levels (/128px) Toda esta seção está muito diferente do que está presente no default.vis do Primo; é por isso que não aparecem os rótulos do jeito que você gostaria. Não cheguei a prestar atenção nesta parte durantes os testes que fiz hoje mais cedo com o Amigo. Só sei que tenho esperança de que o meu default.vis para Primo modificado por mim funcione também no Amigo, pois cheguei a iniciar normalmente (mas tive que mexer no color.ini das suas schemes, no campo [icon], como lhe falei). Agora resta saber se o executável do Amigo está apto a ler os novos comandos do default.vis e executá-los corretamente -- ainda não testei isso também. Se conseguir executar, então tem chances dos labels aparecerem corretamente, pois ajuste de cores é feito no color.ini das schemes. Vou ver isso também. Vamos continuar nossos testes, vou reportar tudo o que conseguir obter, resultados positivos e negativos, pois assim a gente tem mais chances de obter sugestões de outras pessoas. Grande abraço!

Cláudio, para você inciar seus testes aí: http://www33.zippyshare.com/v/PgUc5PrA/file.html "Limpei" as linhas desnecessárias e deixei com a ordem usada pelas schemes da Becker. Depois inseri as novas. A partir deste ponto você poderá rever as cores e usar de acordo com suas preferências. O local das linhas ficou diferente das schemes AD & XA, mas todas estão presentes. Cores das ruas: a resposta está justamente no arquivo default.vis, que é o grande responsável por esta parte. Como já lhe falei certo dia, não tenho um aplicativo para descompactar arquivos de extensão .gro usado pelo Amigo, mas tenho um iGO8 aqui e que me permite pelo menos exemplificar. Veja os dois blocos abaixo (retirados do default.vis, o primeiro é para Primo e o segundo é para iGO8): [Z460km-620km] ; 1 2 3 ;FOW 01234567890123456789012345678901 show = 24, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" width = 24, "11111111111111111111111111111111" color = 24, "AAAAAAAAAAAAAAAAAAAAAAAAQBAAAAAA" show = 25, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" width = 25, "11111111111111111111111111111111" color = 25, "AACCCCCCCCCCCCCCCCCCCCCRQBCCCCCC" [Z460km-620km] ; 1 2 3 ;FOW 01234567890123456789012345678901 show = 24, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" width = 24, "11111111111111111111111111111111" color = 24, "AAAAAAAAAAAAAAAAAAAAAAAAWXAAAAAA" show = 25, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" width = 25, "11111111111111111111111111111111" color = 25, "AAAATTTTTTTTTTTTTTTTTTTAWXTTTTTT" A sigla FOW significa "Form Of Way", ou seja, a forma da via. Os números nesta linha significam o tipo da via, que são de 32 categorias -- isto é, quais serão usadas. As letras que aparecem nas outras linhas podem ser maiúsculas ou minúsculas, não faz diferença, porém um A é diferente de um B. Os números à frente (no exemplo, 24 e 25) é o código do FOW, ou seja, determina o tipo da via. Compare as linhas color de cada bloco (Primo e iGO8). Notará que existem letras diferentes na mesma posição. É por isso que as cores para a mesma via ficam diferente nos dois navegadores. Estas letras são aquelas que aparecem no color.ini das schemes, ou seja, aquele par de linhas do tipo A= e a=, os preenchimentos externo e interno das cores das vias. Como as letras usadas no Primo e no iGO8 são diferentes, então, no color.ini, uma linha que representa, por exemplo, via para pedestres, representará coisa diferente em cada navegador. Como o Amigo guarda grande proximidade com o iGO8, então acredito que ele siga as mesmas estruturas de cores. Não tive tempo para testar o default.vis que modifiquei no iGO8 ou no Amigo, mas basicamente a estrutura é muito parecida entre eles. Assim, acredito que não deveria dar erro. Sugiro que você use o novo default.vis em seus testes, inserindo-o na pasta ui_igo_easy\common de seu pacote Amigo. Deixe o original do data.gro do jeito que está. Para saber se funcionou (claro, primeiro é saber se não apresenta erro ao iniciar o navegador), basta ir no menu Procurar e localizar alguma grande cidade, como SP ou RJ, e verificar as novas superfícies artificiais (cemitérios, hospitais, shoppings, etc.) estão surgindo e com cores individuais (antes não era assim). Outro teste interessante é procurar no mapa uma região litorânea e verificar se as cores do oceano (só funciona no TT) estão divididas em dois tons de azul (como nas figuras de meu post de ontem). Sim, as suas schemes linkadas acima já estão preparada para isso. Mas antes de fazer seus testes no Amigo, sugiro primeiro fazer um teste com as novas schemes em um Primo. Tem algo que poderá dar erro no Amigo e que você precisará corrigir antes de testar. Na seção [icon] do color.ini existem linhas indicando vários arquivos .spr e que "chamam" bmp's no data. Várias linhas que começam com a palavra "cursor" são para Primo e usam arquivos presentes na pasta da resolução da skin (padrão ou diMka) e que não aparecem no iGO8 (acho que é o mesmo caso do Amigo). Ou se usa os arquivos do Primo (colocando-os em uma pasta externa ao data) só para não acusar falta de arquivo, ou se retira/comenta as linhas que sabidamente não têm os correspondentes spr/bmp no data. Tendo estes cuidados, acho que tudo funcionará corretamente. Se não der certo, me avise para que possamos trocar mais algumas ideias até encontrarmos uma solução. Grande abraço!

Pessoal, mais uma lição do tipo "aprender a pescar". Esta parte eu não encontrei claramente em lugar algum do mundo, porém uma parte expressiva foi obtida (por mim - não sou tímido para assumir) por dedução lógica e muitos testes. Mais do que isso, funciona; as minhas informações estão corretas. Basicamente o arquivo color.ini das schemes trabalham com quatro grupos de parâmetros. Quando nem todos são usados é porque o(s) ausente(s) usa(m) o valor padrão. A parte mais importante e desconhecida dizem respeito a parte das superfícies artificiais (praças, parques, matas, rios lagos, oceanos, shopping, campo de futebol, etc.). Os parâmetros são: <Shape name>=<texture_id>, <R>,<G>,<B>, <shade profile> Significados dos parâmetros: Shape name = nome da forma: usado como está definido no banco de dados no mapa. A opção "Unknown_Object" é usada para formas perdidas/indefinidas. Aqui, "formas" são regiões poligonais presentes na tela de mapa. Por exemplo, a pista de um aeroporto, o terreno indicando um hospital, etc. texture_id: identificador da textura. Esta obsoleto; usa-se o valor -1 ou se mantém o valor original. Se texture_id=-1, então é a cor RGB que será aplicada. Os código das texturas estão logo abaixo. <R>,<G>,<B> = código de cores no padrão RGB. shade profile: perfil de sombreamento. Descreve como o polígono será sombreado com base no terreno. Os valores são: 0 => valor padrão. O polígono é preenchido com a cor RGB definida, porém é mesclada com o sombreamento calculado a partir do terreno (isto é, o arquivo day/nightheightcolormap.bmp também é usado). Ou seja, a cor não será sólida, será sombreada. 1 => a cor RGB definida é ignorada, a área do polígono será preenchida com as cores definidas pela elevação (day/nightheightcolormap.bmp) e sombreada pela elevação também (uso do arquivo day/nightheightcolormap.bmp a partir do arquivo DEM). Em resumo, com o valor 1 as cores presentes no arquivo day/nightheightcolormap.bmp é que serão usadas. 2 => nenhum sombreamento, as cores serão sólidas, sem sombreamento e sem influência da elevação. Os pixels no polígono serão sempre aqueles definidos pela cor RGB. Com este valor os arquivos DEM e day/nightheightcolormap.bmp são ignorados. Obs.: os valores para o identificador da textura (texture_id) são: 0 = construções 1 = áreas arborizadas em cidades 2 = áreas industriais, pistas de aeroportos, vias férreas 3 = florestas 4 = parques 5 = cemitérios 6 = águas 7 = áreas ferroviárias 8 = áreas urbanas 9 = fundo/solo Detalhe: como afirmado resumidamente acima, as texturas para as superfícies artificiais não funcionam mais nos novos navegadores da família iGO (Primo e NextGen com certeza) -- acho que funcionava em iGO8 em antigas versões (meus testes não se confirmaram no Amigo). Para efeitos de entendimentos, deixei dois arquivos de texturas que seguem o padrão "antigo" nas pastas gfx\day e gfx\night, nomeados de texture1.bmp e texture2.bmp, para aqueles que quiserem entender a lógica usada naquele tempo. Apesar de ser recomendado usar o valor do identificador de textura (texture_id) igual a "-1", sugiro usar com cautela. Este valor implica em usar a cor RGB indicada, mas há outro parâmetro, o "shade profile". Ainda não testei se este parâmetro é obedecido caso se escolha o valor "-1" para o texture_id. Como foi dito acima, o shade profile determina (a partir dos valores 0, 1 e 2) se a cor será sólida, sombreada (pelo day/nightheightcolormap.bmp) ou se a cor será exatamente aquela do arquivo day/nightheightcolormap.bmp. É preciso mais testes, comentários e sugestões. []'s

Pessoal, aqueles que conhecem o meu estilo de ser sabem que prefiro ensinar como as coisas funcionam, sem esconder o jogo, mas não me importando de preparar algo para aqueles que têm menos tempo ou disposição. Assim sendo, para quem quer saber o que fiz para aparecer as duas cores em tons diferentes no oceano, deixo um detalhe (que deve ser alterado no color.ini da scheme): procure pelas linhas abaixo e deixe-as iguais (ou do jeito que preferir) assim: intermittent_river_or_stream=6, 129,169,222, 2 ; rio ou corrégo intermitente intermittent_water=6, 129,169,222, 2 ; águas intermitentes ; intermittent_lake=6, 129,169,222, 2 ; lago intermitente (não categorizado) ; lake=6, 129,169,222, 2 ; lagos large_lake=6, 129,169,222, 2 ; grandes lagos major_lake=6, 109,149,202, 2 ; lagos importantes (TT. Oceanos - Here) other_lake=6, 129,169,222, 2 ; outros lagos small_lake=6, 129,169,222, 2 ; pequenos lagos ; river=6, 129,169,222, 2 ; rios (Here e TT) major_river=6, 129,169,222, 2 ; rios importantes (Here. Parte costeira dos mares e oceanos e represas - TT) other_river=6, 129,169,222, 2 ; outros rios small_river=6, 129,169,222, 2 ; pequenos rios ; ocean_or_sea=6, 109,149,202, 2 ; mares e oceanos salt_water=6, 109,149,202, 2 ; água salgada stream=6, 129,169,222, 2 ; córregos sweet_water=6, 129,169,222, 2 ; água doce wetland=6, 176,255,176, 0 ; pântanos e áreas alagadas Tomo como base as schemes AD & XA, mas o procedimento pode ser usado em qualquer outra, a ideia é a mesma. Observem que as variáveis major_lake, ocean_or_sea e salt_water têm cores diferentes (usam o RGB 109,149,202, as demais usam 129,169,222). O mapa da TT usa a cor para água doce (rio) para a parte menos profunda nos oceanos e usa a cor setada em major_lake para as mais profundas. Sim, é estranho, mas nada contra assumir que os oceanos são na verdade "grandes lagos". hehehehe Bem, estas mod's devem ser feitas em qualquer scheme do pacote anterior (repito, em breve vou atualizar tudo, mas para quem gosta de aprender e brincar, vale a pena), mas desde que usado o arquivo default.vis que modifiquei e coloquei no pack anterior (isto é, ele deve ficar na pasta ui_igo9\common), pois é ele que faz a diferença em tudo. Para aqueles que quiserem entender o que fiz no default.vis a coisa é simples: siga até o final do arquivo (basta abrir com o Bloco de Notas) e verificar o último bloco do arquivo (lá no final) e comparar com o default.vis original (que fiz na pasta data.zip\ui_igo9\common). Verá que setei todos os comandos com novas variáveis, só trocando maiúsculas por minúsculas. Levei estas novas variáveis para o color.ini das schemes e assim foi possível escolher as cores para cada categoria. E por que nem todas funcionam? Simples, os desenvolvedores de mapas não as adotaram em sua plenitude! Mas o que fiz libera tudo, inclusive já usado pelos desenvolvedores e que não aparecem nos navegadores da família iGO. Este é o caso da cor do mar. Por exemplo, existem 18 categorias de "água", mas todas estavam setadas como "sweet_water" (água doce), ou seja, podia-se até mudar a cor da água salgada, mas nenhum efeito aparecia -- agora aparece! Para aqueles que querem saber mais, duas opções: (1) me perguntar (responderei, prometo! kkkk) e (2) olhar atentamente o que descrevi no arquivo color.ini das schemes nomeadas AD & XA (ali tem mais detalhes). Observem que expliquei as coisas, mas de forma resumida (no color.ini), pois é um arquivo que não deveria ser muito grande). Por isso os detalhes devem ser tratados aqui, em fórum aberto, bastando me perguntar (inclusive pelas falhas de entendimento e tradução). Abraços a todos! Edit 1: amigo Cláudio, tomei a liberdade de editar as suas schemes (que levam seu nome) usadas no Amigo. Só inseri as novas linhas, mas o resto eu mantive (sempre mantenho a base de cores originais). Fará parte do novo pack que vou disponibilizar (e se me autorizar). Caso as queira antes, me avise, posto aqui. Talvez seja preciso ajustar uma ou outra coisa para o Amigo e iGO8 (posso lhe dizer onde). Edit 2: Rafael, fiz o mesmo com uma Fast Ultimate que encontrei "por aí", não sei se é a mais atual. Peço que modifique-a, caso queira, é óbvio, e disponibilize para todos. O patamar se ampliou, não estou conseguindo dar conta de tantas portas que se abriram. Veja com calma, o que fiz foi apenas um tentativa inicial, mas o seu trabalho original é o que conta. Vamos juntos mais uma vez!

Fernando, insira estas linhas em seu sys.txt e veja se há algum resultado positivo: [dynamiccompressor] compressor=1 gain=12 ; (define it only if thrs and ratio don't help [-20dB,8 gives 7 for gain]) highpass_freq=0 a0=56806 thrs=24703 ratio=9 ; (min=0 max=9) Se não der resultado positivo, insira estas aqui também (igualmente no sys): [guidancecompressor] compressor=1 highpass_freq=0 thrs=-20dB ratio=8 ;gain=30 ;[Configurar este parâmetro somente se thrs e ratio não ajudar (thrs=-20 dB e ratio=8 implicam em gain=7)] Se ainda não der resultado, me avise para ver outra sugestão. Abração!

Pessoal, vi que algumas schemes AD & XA estavam com cores que usei para testes e que não deveriam ter ido no último pack; me desculpo com todos. Em breve vou linkar no pack, com correções e acréscimos. Agora vejam o que este pack nos permite (descobrir, saber e usar -- tem recursos que não acaba mais!). Observem as cores do mar nas duas figuras a seguir: Notaram a diferença da tonalidade azul? Este é um recurso que está disponível no mapa da TT (no da Here não é assim, fica na mesma cor). Ele separa a parte menos profunda do mar (chamada de águas marrons) da parte mais profunda (chamada de águas azuis). Grosso modo, nas águas azuis é que se encontra o pré-sal. Nesta scheme (uma AD & XA, mas todas deste tipo serão assim), a cor mais clara é usada para rios e a parte menos profunda do mar, ficando o azul mais escuro para oceanos (ou a parte mais profunda). Usando-se mapa da Here toda a cor do oceano fica a mesma, no caso o azul mais claro (já era nesta cor e nesta scheme). Se entenderem que este é um recurso interessante, então farei as modificações nas demais schemes, porém isto demorará um pouco mais, pois cada uma usa uma cor diferente para águas, mas sem problemas. Por fim explico o que me motivou a fazer isso: hoje estive olhando o editor de mapas da Here e lá é possível visualizar dois tipos de cores para oceanos: parte menos profundo e mais profunda. Achei estranho, pois sabia quera era assim com o mapa da TT. Modifiquei as cores para que o visual ficasse semelhante. O interessante é o site da Here ser assim, mas seus mapas para navegadores iGO não. Ou ainda não descobri onde mexer... []'s

Fernando, este pack tem um grande diferencial: um arquivo default.vis modificado e que habilita novos recursos e novas cores na tela de navegação. Ocorre que o citado arquivo fica justamente na subpasta ui_igo9\common. Se você não usar esta subpasta, nenhum recurso novo aparecerá para você (e pode afetar outras coisas). Sugestão: copie a subpasta ui_igo9\common do pack e cole dentro da pasta ui_igo9 de seu Infinity. Não precisa mexer em outras coisas de seu navegador. Teste e me fale depois se deu problemas. Abraços!

Pessoal, testei os links do Nelson e eles funcionam. Detalhe: usando Firefox. Alguns navegadores apresentam problema mesmo. Basta digitar o código, aguardar alguns segundos e clicar no botão "download" que surge. Nada de redirecionamento aqui. Aliás, amigo Nelson, desta vez os links estão durando! :rindo: Abraços!

Pessoal, atualizei os links no primeiro post. Agora são 48 novas schemes, incluindo aí as solicitadas pelo amigo Coelko. Também houve correção nas schemes Becker. Além disso, tudo foi reorganizado por resolução. Em cada pasta "Primo" existem três subpastas: ui_android, ui_igo9 e ui_nextgen. Deve-se usar apenas uma dela, isto é, de acordo com o tipo de navegador e sistema operacional. Aqueles acréscimos que fiz depois do primeiro post já estão contemplados no novo kit. Foi adicionado uma pasta (Primo High) para que resoluções acima de 800x480 possam funcionar melhor. Abraços. Edit: esqueci de mencionar, mas as schemes adicionais têm nomes seguindo o modelo padrão. Assim, para que apareça na tela de seleção de schemes nomes "mais adequados", sugiro que as linhas abaixo sejam inseridas no dictionary.lang (do arquivo lang, de idiomas). Claro, trata-se de uma sugestão, outras "traduções"/nomes podem ser usados.

Coelko, obrigado por suas schemes. Já estou adaptando todas elas, inclusive várias outras de uso popular. Ou seja, vou disponibilizar mais 24 schemes no total, incluindo as suas. Paulo, realmente existem schemes muito "bugada" por aí. Houve uma época em que as pessoas (daqui e estrangeiros) experimentavam de tudo, mexendo não só nas cores, mas na indicação dos locais onde ficam certos bmp e spr. Se estes não forem encontrados no lugar indicado no color.ini, simplesmente trava tudo. Este é um dos riscos de baixar schemes por aí sem conferir antes. Também já tive muito aborrecimento com isso. Como disse acima, estou adaptando várias schemes de uso rotineiro, para que todas elas, incluindo as postadas ontem, fiquem em conformidade. Assim tem-se um conjunto de novas schemes (isto é, as anteriores, porém readaptadas ao novo) com tudo funcional, sem reset e sem acusar falta de arquivos. Se não for possível terminar hoje, no máximo amanhã com certeza. Abraços aos amigos!

Coelko, caso queira insistir em seus testes, faça o seguinte: (1) Faça um backup de sua pasta GFX que fica na raiz de seu navegador Primo, bem com de todas as schemes (que ficam em \content\scheme). (2) Apague toda a pasta GFX e todas as schemes em seu pacote. (3) Use a nova pasta GFX que disponibilizei e apenas as novas schemes (as de ontem), nenhuma outra (por enquanto). (4) Se não existir, crie a subpasta ui_igo9\common e insira nesta o novo arquivo default.vis. (5) Abra o arquivo system.ini da pasta \save\profiles\01 e deixe-o assim (ou seja, altere só as linhas abaixo): [interface] current_day_color_original_name="AD & XA v6.0 (Dia)" current_night_color_original_name="AD & XA v6.0 (Noite)" O erro que aí se apresentou foi pelo fato de você usar schemes antigas, que provavelmente indicam algum arquivo que não está presente. As novas estão corretamente ajustadas. Outra possibilidade é fazer um teste mantendo apenas a sua pasta GFX atual (isto é, sem usar a nova), pois provavelmente é compatível com as antigas schemes. E sigamos conversando... Abraços!

Coelko, não entendi o que você quis dizer com "erro de executável". Desconheço algo do tipo, mas você poderia ser mais claro? Tipo, qual tipo de mensagem apareceu? Não precisa ser exato, só para eu tentar entender. Outra coisa, eu não uso o mesmo executável que você usa, o meu tem final 290290, mais antigo, porém confiável. Tive muita dor de cabeça com o executável 405512, mas nem por isso posso condená-lo. Erros oriundos das schemes se devem a falta de arquivos na pasta GFX e que estão setados em determinada scheme. Como está escrito no txt incorporado, isto com as instruções e comentários, velhas schemes não funcionarão obrigatoriamente com a nova pasta GFX, mas principalmente terão problemas com o novo arquivo default.vis. Se você voltar a testar os novos arquivos, sugiro que use apenas as novas schemes. Caso o problema persista, além de me avisar para ver o que está acontecendo, peço-lhe que indique qual é o nome da scheme selecionada. Além disso, antes de usar o novo "kit" sugiro apagar a Save. Na verdade não precisa apagar toda a pasta, basta apagar todos os arquivos da subpasta \save\preloads e os seguintes arquivos da subpasta \save\profiles\01: lua__persistent_.sav e mapstates.ini. Só fazendo testes e mais testes teremos algo novo e realmente funcional. Por isso sempre peço que as pessoas relatem suas experiências, boas ou desagradáveis. Abração e obrigado! Edit: mensagem em chinês significa que o erro foi no sistema operacional (WinCE) do aparelho. Isto ocorre quando um bmp setado em uma scheme ou skin não é localizado. Provavelmente você trocou os arquivos pelos novos, mas esqueceu de mudar a scheme (provavelmente incompatível com o novo kit). Para mudar a scheme que será carregada é muito simples: (1) Entre na subpasta \save\profiles\01 e localizer o arquivo system.ini. (2) Abra este arquivo com o Bloco de Notas e localize a seção [interface], que está logo no início. (3) Deixe, para efeito de testes, as seguintes duas linhas como indico abaixo: current_day_color_original_name="AD & XA v6.0 (Dia)" current_night_color_original_name="AD & XA v6.0 (Noite)" (d) Salve o arquivo e inicie o Primo. Observe que só se usa no nome da scheme, isto é, a extensão (.zip) não é inserida.

Pessoal, notei uma falha estranha ao traçar certas rotas já conhecidas (com o default.vis originalmente postado): um cálculo totalmente diferente e inesperado. Fui olhar o default.vis, notei que usei o original (do Primo), alterado apenas lá no final, nas variáveis para as cores do mapa. Não deveria ocorrer o que vi. Serve de motivação para nossos estudos. De qualquer forma, usei um default.vis que tinha em um módulo ux, mas com o final (as cores visuais) do jeito que eu havia modificado, só isso. Deu certo (aparentemente). Usem os arquivos com moderação, pois ainda estão em fase de testes. Acho que não tem nada grave (desde que o default.vis seja trocado: veja o post acima, que foi editado e com novo link). Espero que todos colaborem com comentários, críticas e experiências. Só assim ganhamos todos. Abraços "desculposos".

Pessoal, como havia comentado em outro tópico, deixo aqui links (senha: GPS Clube) para novas schemes (48 no total), pasta GFX e um novo default.vis: Leiam as instruções e comentários no arquivo txt que segue em conjunto. Não vou detalhar tudo aqui, somente se perguntas e questionamentos surgirem. Aí será post por post. Observo que ainda está em fase de testes, mas acho que já consegui muito do que queria. []'s PS: postado primeiro neste fórum. Registre-se!!! Atualizado em 27/10/2019: Download: GPS Clube.txt Instalação: Instalação.txt PS: os arquivos referentes ao Nextgen não fazem parte do pack acima; ignorar esta parte no txt de instalação.

Chiichobits, tente isso: 1) Faça um backup de seu navegador GPS. 2) Você usa o MapChanger antigo, isso ficou claro. Renomeie suas subpastas da pasta \content deixando (mais ou menos) como exibido na figura a seguir: 3) Caso não tenha a pasta de nome "ux" na raiz de sua pasta Primo crie uma e copie o arquivo abaixo para a mesma. Caso já a tenha, basta copiar o seguinte arquivo para a mesma: http://www.solidfiles.com/v/XGAReNPGR3nWw 4) Abra o arquivo sys.txt e insira esta campo: [mapchanger] map_ta=2017.06 map_nt=2017.Q2 Caso o mesmo já exista, deixe apenas estas linhas acima, comentando as demais (isto é, inserindo um ponto e vírgula -- ; -- antes de cada uma das demais linhas. 5) Para acessar o novo MapChanger, basta ir em Configurações e selecionar/clicar o ícone "MapChanger". A partir daí é possível selecionar entre o mapa da TT ou Here. Deixo aqui duas telas mostrando os novos mapas em um Primo 2.0 (no menu do novo MapChanger, basta clicar em Desenvolvedor para ver a versão do mapa em uso). E para que não restem dúvidas sobre as figuras acima, é mesmo um Primo 2.0 (com executável em sua última versão para este navegador). Veja a figura a seguir: Lamentavelmente, o Primo 2.0 (para WinCE apenas) não reconhece mais o arquivo de junções de extensão .FJV, nem mesmo na versão do executável exibida acima. Quanto aos demais conteúdos, sem problema algum. Boa sorte e boa viajem! Edit; a expressão "Primo 2.4", na última figura acima, é oriunda do branding.zip (que funciona nas duas versões do Primo, 2.0 e 2.4), daí uma provável confusão. O que conta é o número da versão do executável, que no caso é 9.6.5.306142.

Pessoal, estou fazendo alguns testes aqui. Alguns comentários: (1) Não se deve usar os conteúdos da CGIAR (aqueles já conhecidos por nós) juntamente com os conteúdos da NASA (a novidade). Ou se usa os 2 da NASA ou se usa os 3 da CGIAR, caso contrário dará problema ou nunca saberemos qual dos dois tipos está sendo usado. (2) Sempre me chamou atenção uma montanha enorme, entre Ouro Branco de Ouro Preto, que é retratado no Primo como um morrinho qualquer. Em um primeiro teste, realmente não percebi diferença, ao menos neste teste específico, do conteúdo da CGIAR para o da NASA. Nosso amigo Estreiante também não notou diferenças expressivas em seus testes. Para quem quiser testar a montanha/morrinho, segue as coordenadas: Partida: -20.51452, -43.67442 Destino: -20.38489, -43.50360 (3) O maior arquivo da NASA tem 192 MB de tamanho, já o maior da CGIAR tem 199 MB. Verificar só o tamanho não diz muita coisa, mas é certo afirmar que tem diferença. A questão é descobrir um local em que, visualmente falando, a diferença apareça de maneira clara. Isto demanda testes e mais testes. Entendo, para aqueles que querem tentar algo, que se procure por locais de elevações expressivas, onde é mais fácil perceber diferenças entre as inclinações. Bem, é isso. Abraços.

Paulo, este executável que você está usando é o famoso Honda Civic. O que me chamou atenção é que li que este executável não precisa de licença alguma, pois o mesmo é totalmente cr*ck*do. Não sei se é por isso que você está tendo problemas aí. Na prática, não vi vantagem deste seu executável em relação ao que uso, mesmo sendo o meu um pouco mais antigo. Se você não tiver o executável de versão 9.6.13.290290 e quiser testar, me fale. Abraços.

Paulo, na linha abaixo dessa que você olhou tem mais detalhes, isto é, depois dos números 9.6.13 tem mais um número com seis dígitos. Eles são importantes. Mas pelo que já estou imaginando, é o mesmo executável que uso, que tem final 290290. Confira aí. Caso seja igual, volte ao meu post anterior e veja as duas dicas que passei, sendo uma no "edit". Já na dica anterior, ao invés de você substituir os arquivos e pastas que citei, você pode apagá-los, pois o Primo os gera novamente. Acabei de fazer isso aqui em outro aparelho, com velhas licenças, e deu certo. Só deixei as licenças na pasta license e nada mais. Aqui funcionou corretamente. Vamos resolver isso, siga relatando até que uma solução seja encontrada. Aliás, seria interessante que outros membros citassem aqui as suas experiências, para que outros possam se beneficiar também. Abraços.

Paulo, você está usando Primo 2.4, certo? Peço que verifique algo para mim: clique com o botão direito do mouse sobre o executável de seu navegador Primo, escolha "Propriedades" e depois clique na aba "Detalhes". Aparecerá um campo de nome "Versão do produto". Diga-me qual é a versão de seu executável. Por exemplo, o meu é 9.6.13.290290. Estou lhe pedindo esta informação porque as licenças de extensão .lyc não funcionam com o Primo 2.0, este só funciona com arquivos de extensão .lic (troca o "i" por um "y"). Já o Primo 2.4 funciona com as .lyc, mas não pode ser dos primeiros, tem que ser um executável um pouco mais novo, como o da versão que citei e uso. Outro teste é apagar os seguintes arquivos da pasta license (ou substituir pelos seus antigos): ACTIVATION_CODES e device.nng. Além disso, troque as pastas de nomes .reg e server_configs por aquelas que você estava usando antes. Abraços. Edit: se o executável for da mesma versão do que o meu, se a troca de arquivos e pasta não resolver, então como último teste tem-se a possibilidade de apagar toda a pasta Save, mas fazendo um backup antes. É desagradável ter que reconfigurar tudo, mas tem momentos que se tem que fazer isso.

Paulo, faça um backup de sua pasta "license". Em seguida, use apenas as licenças abaixo (GPS Clube): https://nofile.io/f/Emu3RHTJ7xj/license.rar Elas cobrem todos os conteúdos que conhecemos; isso é o bastante. Mas mantenha suas licenças anteriores, caso tenha algum problema e tenha que voltar com elas. Abraços!

Pralima, erro de detecção pode se dar por vários motivos. Mas antes é preciso que você nos diga se nesta CM algum navegador GPS já funcionou corretamente. Isto é importante. Algumas dicas: 1) Coloque port=auto e baud=auto na seção [gps] do sys.txt. Depois apague o arquivo system.ini que fica na pasta \save\profile\01. Não é preciso apagar toda a pasta, somente em caso extremo. 2) Em configurações de rota, verifique se o ponto de partida não está setado com algum endereço e/ou cidade. Se este for o caso, então o GPS estará desligado e o navegador irá sempre carregar o lugar daquele ponto de partida e não a posição real. 3) Se nada acima resolver, a suspeita recairá sobre a antena GPS de sua CM. Se algum navegador GPS funcionava corretamente em sua CM, então o problema pode não estar na antena. Mas nada impede que a mesma tenha queimado (raro) ou o cabo tenha desconectado. Se nunca teve um navegador GPS funcionando adequadamente, então o problema pode estar na antena mesmo. Pode ser por três motivos: antena queimada, antena desconectada, ou antena inserida em um local do carro que deixa o sinal de satélites muito fraco, de maneira que o navegador GPS não conseguirá obter a localização atual. Em qualquer destes casos, sugiro levar sua CM a um técnico de confiança e com experiência comprovada em centrais multimídias. Boa sorte!