Mudlet: Salas de speedwalk de insetos tocando

Criado em 2 abr. 2019  ·  10Comentários  ·  Fonte: Mudlet/Mudlet

Breve resumo do problema / Descrição do recurso solicitado:

Eu tinha notado esse bug nos mapas do Continente da Área ABERTA várias vezes (onde todos os quartos estão se tocando), mas não percebi o motivo pelo qual isso acontece.

Percebi isso em algumas áreas que estava mapeando, onde decidi ter quartos se tocando, tamanho 10 se tocando lado a lado.

Notei que o caminho para antes de onde ele realmente precisa ir, ele assume, porque os quartos estão tocando as bordas, que ele terminou a caminhada rápida.

Etapas para reproduzir o problema / Razões para adicionar recurso:

Em uma área, apenas tenha as salas tocando as bordas e tente clicar duas vezes na sala para ver como ela segue até ela, em seguida, faça com que não se toquem e o caminho funcionará corretamente.

Aqui está uma imagem para ilustrar:

bug-pathing

bug medium

Comentários muito úteis

Veja minha correção para isso - e eu também acabei de encontrar o speedwalk to room no outro recurso de área - que na verdade é o planejado (pelo menos quando o modo de grade está desativado!: Stick_out_tongue_winking_eye :)

Todos 10 comentários

Além disso, diminuir o tamanho do quarto quando os quartos estão tão próximos funciona, mas você tem que diminuir o tamanho do quarto para 7 antes que o bug desapareça ... é muito interessante para dizer o mínimo. sem olhar para o código, não consigo imaginar por que isso acontece. Espero que isso não seja muito difícil de consertar. Eu uso o tamanho 10 da sala e ADORO a aparência da sala 10, então esse bug me deixa triste :(

Eu diria que o código que determina a sala mais próxima da posição do clique do mouse provavelmente tem um ligeiro deslocamento e isso é bagunçado para salas adjacentes. Existem algumas coisas que vêm à mente:

  • pode haver alguma matemática em andamento que produz um resultado fracionário (tipo double ), mas está sendo armazenado ou comparado a int valores e as coisas não estão sendo qRound( ... ) ed antes de ser comparado.
  • algo relacionado - double ou float valores estão sendo testados com uma comparação == - o que nunca é uma boa idéia!

: bulb: Dê uma olhada, deixe-me pensar, T2DMap::paintEvent(...) nos três bits de código que começam com um ìf complicado:

        if (((mPick || __Pick) && mPHighlight.x() >= roomRectangle.x() - (mRoomWidth * rSize) && mPHighlight.x() <= roomRectangle.x() + (mRoomWidth * rSize)
             && mPHighlight.y() >= roomRectangle.y() - (mRoomHeight * rSize)
             && mPHighlight.y() <= roomRectangle.y() + (mRoomHeight * rSize))
            || mMultiSelectionSet.contains(currentAreaRoom)) {

O membro (QPoint) T2DMap::mPHighligtht está definido para as coordenadas x / y onde o evento de duplo clique ocorreu em uma chamada anterior para T2DMap::mouseDoubleClickEvent(...) então eu acho que você vai querer verificar os limites que estão sendo usados ​​para verificar se uma sala está dentro do alcance do clique duplo.

Uma coisa que você vai querer verificar é se o erro é simétrico - isto é, acontece igualmente em ambos os lados e também igualmente acima e abaixo - se for assim, os limites podem apenas precisar ser reduzidos; se NÃO, então há um problema de codificação. observe que alguns desses valores envolvidos no cálculo são, eu acho que float ou double e não int tipos, e que o eixo y é invertido (IIRC) para os 2 Mapeador D ...

Você deve estar certo. Além disso, após reiniciar o mudlet, não consigo mais reproduzir o erro e estou exatamente na mesma área que estava antes. Anteriormente, ele fazia isso todas as vezes e era facilmente reproduzido e agora não consigo fazer isso de forma alguma. Então é quase como se algo tivesse um bug e depois consertado depois de reiniciar o mudlet.

Da próxima vez que esse bug se apresentar, tentarei chamar gotoRoom () e ver se isso também é afetado ou apenas o clique duplo.

Atualização, acho que você acertou em cheio @SlySven O bug reapareceu para mim hoje durante o mapeamento. Eu poderia tentar acessar o quarto repetidamente com um clique duplo e ele continuava bugado. No entanto, uma vez que usei lua gotoRoom(23979) ele foi encaminhado para a sala corretamente.

Para quatro (ou mesmo oito, se estivermos preocupados com as diagonais) salas definidas ao redor do alvo, essa seleção incorreta ocorre uniformemente ao redor do alvo?

Além disso, pode ser que dependa da sequência em que as salas são desenhadas, se houver uma sobreposição na região para cada sala potencial (a primeira sala desenhada que estiver dentro do alcance acionará o processo de caminhada rápida) - e como estamos iterando por meio de um QSet para que o pedido seja indeterminado ...

{Para fins de depuração, pode ser informativo usar a opção de exibição do Id do quarto para exibir a ordem de desenho do quarto - com um contador incrementado após cada quarto ser iterado e redefinido no início de cada T2DMap::paintEvent() : nerd_face:}

isso NÃO acontece de maneira uniforme em torno do destino, por exemplo, se eu propositalmente colocar um punhado de quartos juntos, alguns deles posso clicar duas vezes e mover para eles, outros apenas permanece como se eu já estivesse no meu destino:

layout real:
2019-04-04_17-21_1

aglomerou alguns quartos juntos:
2019-04-04_17-21

com o tamanho 10/10 foi muito fácil de reproduzir imediatamente, parece que você está ligado a algo com eles se sobrepondo de forma diferente dependendo da ordem desenhada, porque com eles aglomerados assim alguns quartos vizinhos iriam caminhar e outros não, também pude ver ao clicar duas vezes na sala que piscou com o alvo vermelho e estava incorreta, indicando que a sobreposição está de fato afetando-a.

isso significa que a superfície clicável dos quartos se estende além da caixa dos quartos? Não entendo por que isso aconteceria ... Clico cuidadosamente no meio da sala quando isso acontece.

isso significa que a superfície clicável dos quartos se estende além da caixa dos quartos? Não entendo por que isso aconteceria ... Clico cuidadosamente no meio da sala quando isso acontece.

Esse seria o meu palpite - eu fortemente suspeito de que há falhas nos testes if me referi anteriormente - (e a ordem de desenho provavelmente está aumentando também - o que não seria um problema se as áreas de seleção fossem precisamente avaliado) ...: preocupado:

Descobri hoje, enquanto mapeava, que clicar em uma sala no limite de uma área às vezes pode levá-lo para fora da área, então o problema se estende a salas em outra área.

2019-04-06_01-23

Veja minha correção para isso - e eu também acabei de encontrar o speedwalk to room no outro recurso de área - que na verdade é o planejado (pelo menos quando o modo de grade está desativado!: Stick_out_tongue_winking_eye :)

Veja minha correção para isso - e eu também acabei de encontrar o speedwalk to room no outro recurso de área - que na verdade é como pretendido (pelo menos quando o modo de grade está desligado! Stick_out_tongue_winking_eye)

ISSO É INCRÍVEL! Além disso, meu modo de grade não usa o modo de grade, hahahaha. Então, acho que posso usar esse recurso incrível. no meu mapeador, eu uso um deslocamento de 2 em x, y para a maioria dos quartos e um deslocamento de 1 nos continentes (onde estou querendo a aparência da grade, com um tamanho de sala de 10/10, isso parece muito bom e tem uma aparência agradável para entradas de área.)

Muito obrigado por consertar este SlySven!

2019-04-07_00-05

Esta página foi útil?
0 / 5 - 0 avaliações