The Mana World Forums

Where a distance of monsters, especially when entering a passage, the monster is paralyzed. This is a known bug in the game.
Analyzing the code, figured out how to run problem. Simply by changing the order of a few lines:

pt_br wrote:Sempre que se distancia de um monstros, principalmente ao entrar por uma passagem, o monstro fica paralizado. Este é um bug conhecido do jogo.
Analisando os códigos, descobri como corrir problema. Bastando apenas trocar a ordem de algumas linhas:

current code:

static int mob_attack (struct mob_data *md, unsigned int tick, int data) {
struct block_list *tbl = NULL;

nullpo_retr (0, md);

if ((tbl = map_id2bl (md->target_id)) == NULL)
return 0;

if (!mob_check_attack (md))
return 0;

corrected code:

static int mob_attack (struct mob_data *md, unsigned int tick, int data) {
struct block_list *tbl = NULL;

nullpo_retr (0, md);

if (!mob_check_attack (md))
return 0;

if ((tbl = map_id2bl (md->target_id)) == NULL)
return 0;

The simplest way to check the problem and the fix is ​​also creating a monster that does not move, offensive and attacking from a distance.
buggy: to distance himself from the monster he stops attacking and is paralyzed.
no bug, it comes back to attack once again reaches the target.

pt_br wrote:A forma mais simples de verificar o problema e também a correção é criando um monstro que não se move, ofensivo e que ataca à distancia.
com bug: ao se distanciar do monstro ele para de atacar e fica paralizado.
sem bug: ele volta a atacar assim que alcança o alvo novamente.

Can someone test this? This is just a proper git patch of the change suggested.

The same patch was made by me for ufb server more than year ago:

https://www.gitorious.org/tmw-ufb-ea/tm ... 0b02a7e16f

It fix one thing but it add another bug, test it and you will see.

If you say that adds another bug, maybe it's because the function does mob_check_attack extra checks.
If the check (map_id2bl tbl = (md-> target_id)) == NULL before this function is more accurate, then you need to give appropriate treatment rather than return 0;
The second bug you say, maybe the monster is not to chase their target. So we need a logic to expect that stationary target for his return and then keep attacking. And it can change target too.

pt_br wrote:Se você diz que adiciona outro bug, talvez seja porque a função mob_check_attack faz verificações extras.
Se a verificação (tbl = map_id2bl (md->target_id)) == NULL antes desta função for mais correto, então é preciso dar um tratamento adequado ao invés de return 0;
O segundo bug que você diz, talvez seja do monstro não perseguir seu alvo. Então precisamos de uma lógica para que estacionários esperem por seu alvo retornar e continue atacando depois. E ele possa mudar de alvo também.

Thank you for your attention.

I think you didn't understand the nature of the bug.

The function mob_check_attack does not do extra checks since as you can read in this line
http://gitorious.org/tmw-eathena/mainli ... .c#line829 the check is duplicated which imply that this code does, if the condition is true, double check on the same thing, i think that you probably missed it.

Also changing the return value of the mob_attack function is useless since the return value is always 0 and it's never checked in any part of the code.

In my opinion it's not a good practice to add new code to fix a bug until you do not have a clear idea why it exists and how you may fix it but i may be wrong.

Now, leaving all that on one side, the flower is stucked due to that double line, the reason why swapping the lines fix the issue comes from this other one http://gitorious.org/tmw-eathena/mainli ... .c#line814
the mob status is set to idle while this do not happen when the first if fails, the flower stucks on the attack status which brings its paralysis.

By fixing that in the proper way, which i won't explain in detail using the code since it's obvious; change the return values and the returned variable type in mob_check_attack, removing the double check, etc, etc...
you will end up with a solution for the paralysis but there will be a new issue, now the mobs that were following a player will stuck on the entrance of the caves where he or she left, this, until a player would enter in that map and move them away.

I was poking around some other stuff and found some files in ~/.local/share/mana/updates/updates.themanaworld.org/fix ... who ships these and why don't they put them in the main repository? (Edit: found this, as I guessed)

One of the live files is the flower mob (the other is for items.xml and I don't feel like touching that) and I remember seeing it's animation continue looping while playing with this patch ... I guess this fixes *that* problem?

I really want to see this bug fixed but I don't have the time to fully understand it ... and those who apparently do, are not very forthcoming. Maybe this could be applied on the test server for a while?

Anyway, I've attached the diff for client-data/fix/update-that-contains-flowers.zip

o11c wrote:I was poking around some other stuff and found some files in ~/.local/share/mana/updates/updates.themanaworld.org/fix ... who ships these and why don't they put them in the main repository? (Edit: found this, as I guessed)

This is fixes for clientdata for manaplus what was rejected (or will be rejected) by some tmw people.
Some features from here still not supported by "official" (tm) client.

Hi,

4144 wrote:This is fixes for clientdata for manaplus what was rejected (or will be rejected) by some tmw people.
Some features from here still not supported by "official" (tm) client.

Sorry, but this is wrong as the code to support the <end /> tag is there in the src/resources/spritedef.cpp line 284.

It is thus supported or at least should be and was broken. I'll try it on the 0.6.0 client and look into fixing it if not already done.

Please, 4144, I'm in very good term with you, and I wish you could name the people involved with the rejected features instead of involving the whole (tmw, but I guess more mana, in that case) team, which is atm concerning only bjorn, Ablu and me.
You're right some features got rejected, and I'm sure some were rejected for bad reasons, or badly exposed. Let's try to make the future of this project a better place for sharing.

Best regards,

Bertram

I see otherwise the target doesn't get reset and will continue to loop on the same target.

Github patch