Possible bug - attacks pausing and graphical glitch


#1

First, when my hero is about to attack, I sometimes see this ^ graphical glitch appear. Not sure why my hero looks like that, but it’s not game-breaking so I’ll ignore it.

The real problem is that for some reason, I’m now experiencing what appears to be a game-breaking bug where I write an attack loop for my hero and the hero just pauses after a few attacks instead of fighting the next enemy. This has already shown up in the Sarven Shepherd level preventing me from progressing. I thought it might be specific to that level so I tried Cavern Survival and got the same problem.

I’ve tried it in Chrome and Firefox and gotten the same results.
The code is in Lua (I haven’t tried changing that yet).

My code should be fine (as far as I can tell):
i = 1
loop
    enemies = self:findEnemies()
    
    while i < #enemies do
        if self:distanceTo(enemies[i]) < 15 then
            if enemies[i].type = "munchkin" then
                self:attack(enemies[i])
            elseif enemies[i].type = "door" then
                self:attack(enemies[i])
            else
                self:say(enemies[i].type)
            end
        end
        i = i+1
    end
end

If anyone has any suggestions of what might be the problem or what I should try next I would appreciate it.


#2

What weapon do you use? If it has a long recharge, the wait should happen.


#3

The pic appears like Ghost Hero, previously reported by @ChronistGilver


#4

Your code is set up so that your hero only acknowledges mobs within 15 (meters/feet/whatever). So, if the mobs are more than 15 away (and some ranged mobs set up outside that range), they would be ignored in this loop. So - first question - does the pause happen when the mobs are some distance away from your hero?

Second - you are currently only attacking “munchkin” and “door” if I’m reading this right. The “say” command for any other type can pauses the execution of attacks as well.


#5

I had been using the long sword and then switched to the claymore.

I guess I wasn’t very clear, so I apologize for that.
The problem is that the hero (in the cavern survival level) hits the door once, kills 2 munchkins (one hit each) and then just stands there being attacked by an increasing number of munchkins for about 9 seconds.

The hero didn’t actually say anything, so I had assumed that the enemies were all munchkins and doors (until I die) but to confirm: when I replace the say command with an attack command (ensuring that all enemies get attacked and there is not pause to say anything) the behaviour stays the same.

Thanks for the suggestions.


#6

If the hero never resumes attacking, that is usually a pretty good indication that the compiler didn’t like something in your code. Question … does Lua use the “==” in the “if” statement?


#7

You are correct that it should be == but that doesn’t seem to be causing problems; I fixed it and nothing changes.
The hero does actually attack once more (after the 9 second pause) and then pauses again until the hero dies.


#8

What glasses do you have on? I’m wondering if you’re trying to attack an ogre on the other side of the wall or otherwise not reachable from your current position. (Do you have access to the .isPathClear method to test that you can reach the enemy before you attack them?)

Alternatively, are you sure about “#enemies”? (Apologies, I don’t know anything about Lua.)

More generally, why are you using a while loop to go through the enemies when you could simply use the .findNearest method to just identify the closest ogre/door and attack it…


#9

I’m only attacking enemies with a distanceTo < 15 so that shouldn’t be a problem. (I’m using the Fine Telephoto Glasses.)

Well… I am (or I was) sure, but I’m trying to use this to pick up Lua so I did some research.
It looks like the # operator can break if there are holes in the table.
http://www.lua.org/manual/5.1/manual.html#2.5.5

Thanks for your help. :slight_smile:

I managed to fix my problem by using a for loop instead of a while loop.

for i, enemy in ipairs(enemies) do

It seems though that if there isn’t a reliable length option, we probably shouldn’t be encouraged or required to use one. I’m wondering if there might be a level where I can’t use a for loop (for loops aren’t in my book…) and the level is unbeatable in Lua because this # operator prevents while loops from working.


#10

You actually missed my point entirely. I’ll apologize in advance and assume you can translate the following python code:

loop
    enemies = self.findEnemies()
    enemy = self.findNearest(enemies)
    if enemy:
        self.attack(enemy)

This loop is actually a far more efficient way to attack all of your enemies. Instead of looping through enemies, it simply selects the closest one and has you attack that. It will continue attacking the nearest until all are dead.

Now, from my perspective, there is very little advantage, given what you’re doing, in your more complicated for loop. Instead, what about simplifying it a bit (and apologies if I got the syntax wrong):

for enemy in enemies do

With enemy, you no longer need the enemies[i] type reference.

[Edit: Ugh … very nice catch Nick (see below). I can’t believe I missed the fact that the index variable wasn’t get reset in the loop.]


#11

The reason for the more complicated code is that in the levels I was working on there is a requirement to do more than just attack the closest enemy. The code I posted was created almost entirely for testing the problem I was having, but was also partly based on the requirements of the level, that is, I wanted to eventually add a way to decide to attack the enemy hero even if there were closer enemies.

The code I posted could certainly be simplified and improved, but the more advanced logic which I intended to include required a more complex framework than simply attacking the nearest enemy; it required a loop to look at all the enemies and prioritize based on the enemy type.

All that aside, I appreciate your help. The problem I was having seems to be caused by the way Lua handles the length of arrays and my use of the # operator. In my opinion this makes learning Lua (without prior programming experience) using CodeCombat extremely difficult as the instructions say to use # for array length and there is no way to know that a for loop will work better (or even that you’re allowed to use one). Perhaps @nick can comment on this?


#12

Also, make sure your browser is up to date. If it still doesn’t work, try using internet explorer. Then try refreshing your history, your cache, and cookies. Try checking your CPU usage and deleting or preventing activity of unnecessary apps that run in the background or on startup. Hope I helped.


#13

Sorry, I looked it up, and I noticed that Lua is a programming language.


#14

Ah, I see. Your main problem is that you set i = 1 outside the main loop, so it never resets back to 1 to go through the enemies array again. You attack every once in a while when a new enemy spawns within 15 meters. Try moving that inside the main loop.

I think you will also want i <= #enemies becauseof Lua’s 1-based array indexing.

You’re correct that ipairs is a better way to loop through an array in Lua; we do the while-loop-based one first because we think the progression through concepts is better for learning, but if you know ipairs, go ahead and use it.