Mudlet: Solicitação de recurso: Mudlet Lembre-se da quantidade de zoom do mapeador entre as sessões.

Eu prevejo que a configuração de zoom por área é uma grande quantidade de dor, já que ele será redefinido entre as áreas na primeira vez e assim por diante. Lembrar do zoom entre as reinicializações seria bom, entretanto, apenas jogar https://wiki.mudlet.org/w/Manual : Mapper_Functions # setMapZoom em um script é uma solução trivial para isso!

: bulb: Não se esqueça de que hoje em dia existem dados de usuário de área, portanto é possível armazenar dados por área - consulte setAreaUserData(...) e getAreaUserData(...) !

Pedido antigo, mas eu falarei.
Concordo que setMapZoom combinado com setAreaUserData e getAreaUserData ajudará, no entanto, sem um "getMapZoom" ou uma forma semelhante de "obter" o nível de zoom atual, ele será controlado de forma arbitrária ou manual. Se eu puder detectar a mudança no nível de zoom, armazene-o em areaUserData e configure-o sempre que o mapa for carregado ou as áreas forem alteradas, seria perfeito

O nível de zoom do mapa é, infelizmente, controlado em mais de uma maneira que não se comunica entre si. no mapa 2D você tem a roda do mouse (vertical) e o setMapZoom() que eu acho que podem ser feitos para funcionar em conjunto. No entanto, o mapeador 3D é um café da manhã de cachorro certo. Você tem a roda do mouse (vertical) e o controle "Escala" (o controle deslizante mais à esquerda) que mais uma vez meio que funcionam juntos - mas existem três outros controles que definem as posições das coordenadas do sqrt(x^2 + y^2 + z^2) ou seja, a famosa fórmula de Pythagorus), também controla o zoom efetivo. calcular o efeito geral não é previsível no momento ... AFAICT

hahahaha atualmente eu só uso o mapeador 2D para que funcione bem para mim :)

Mapeamento 3D ?? Eu nem sabia disso: DI também usei o mapa 2d.
(anota para investigar o mapeador 3D: D)

mas com métodos adicionais de "obter" para o nível de zoom atual (para 2d) e para posições e escala para 3d, tenho certeza que o ppl rapidamente faria com que as áreas tivessem zoom e pontos de vista persistentes :)

Pode ser necessário um evento para a roda do mouse, se não houver um também.

(isso não é um grande negócio para mim, pois leva apenas cerca de 2 segundos para rolar qualquer área que eu inserir na escala correta de qualquer maneira, e eu provavelmente poderia brincar com setMapZoom para persistir isso, apenas pareceria "desajeitado" ter que definir isso manualmente, e não apenas persistir em tudo o que apliquei zoom da última vez que visitei aquela área)

.... seria apenas "desajeitado" ter que definir isso manualmente, e não apenas persistir o que quer que eu ampliei na última vez que visitei aquela área

Então você iria querer:

• um sysMapperAreaViewedEvent que dispararia conforme a área fosse alterada (retornando os IDs de área antigos e novos) e dispararia pouco antes de a visualização ser mudada para fora da área antiga.
• algo para retornar ao modo de visualização atual {visualização 2D / 3D, coordenadas atuais do centro de visualização, mapa 2D (somente zoom) ou mapa 3D (configuração de zoom / escala e coordenadas de posição dos olhos)}

:pensamento:

Provavelmente também precisa de meios da API Lua para configurar todos esses detalhes também ...

Sim para o sysMapperAreaViewedEvent e seus retornos.
(necessário para detectar a mudança, armazenar o zoom antigo para a área antiga, pegar um novo zoom para a nova área)

Para obter todas as propriedades do "modo de visualização", não estou 100% certo de que você precisa fazer o full tilt inicialmente. Atualmente existe apenas um setter "setMapZoom (zoom)", o que significa que pode-se começar com o getter "getMapZoom ()". (o que significa que isso só funcionaria "corretamente" para o modo de visualização 2D inicialmente.

Isso poderia ser expandido com suporte 3D, granularidade de área, armazenamento de nível de zoom no próprio mapa ou construção de persistência no aplicativo. No entanto, isso provavelmente pode esperar até que haja uma demanda?
(normalmente, eu recomendaria "fazer as coisas certas" no início, no entanto, não sei o tamanho da demanda por 3d, e prevejo que a ativação de getters para esses recursos geraria logicamente uma demanda de setters para alterar as propriedades do modo e modo de exibição)

(Eu não sei a sobrecarga de configurar uma nova função no Mudlet, embora possa imaginar que é um pouco (código, teste, documentação, etc.). Conforme declarado, este não é um recurso extremamente necessário para mim. queria começar a dar uma olhada no código por conta própria, poderia ser um motivador para que eu voltasse a codificar: D) (devo dizer que realmente amo Mudlet. Isso me trouxe de volta a alegria do mudding)

Acho que, neste ponto, faria sentido apenas incluí-lo como um recurso Mudlet, em vez de fazer com que todos recodificassem por conta própria. Poderíamos armazenar o zoom do mapa por área como um recurso de dados do usuário da área.

Eu prevejo que a configuração de zoom por área é uma grande quantidade de dor, já que ele será redefinido entre as áreas na primeira vez e assim por diante.

Se você entrar em uma nova área pela primeira vez que ainda não possui uma configuração de zoom, comece com a área anterior.