This site requires JavaScript, please enable it in your browser!
Greenfoot back
Twitter Twitter.hover
Gingervitis
Gingervitis wrote ...

2015/6/6

Actor collision help

1
2
3
danpost danpost

2015/6/6

#
Gingervitis wrote...
The set of MrBoom images are 72x82 pixels The EnemyDamageField 6x6 pixels and is supposed to spawn at the left side of another class 'Skeletor' and those dimensions are 150x150 but that size may be adjusted in the future.
Sorry, I had missed that post (you probably posted that one while I was creating my next post). As such (seeing the size used for the images of the MrBoom object), your 'damage' method is equivalent to the following: 
public void damage()
{
    if (i > 8)
    {
        Actor df = new DamageField(round, MrBoom.class);
        getWorld().addObject(df, getX()+24, getY());
    }
}
The pixel coordinates of (24, 0) are the first ones where a color is acquired. It is also the only one because your incremental values of 'w' and 'h' exceed the width and height of the actor. All pixels that are checked within the limits of the image will have a color; so the check on your line 131 will always return a true value (at least, I do not think you can set the color of a pixel on an image to 'null'; if so, you would probably have to do it programmatically yourself). The placement of the new DamageField object is not the same location in the world that the pixel of the image is located in the world. Remember that the center of the actor is at (getX(), getY()) and (0, 0) of the image is actually at (getX()-getImage().getWidth()/2, getY()-getImage().getHeight()/2) or (getX()-36, getY()-41) in the world; therefore the new actor should be placed at (getX()-36+w, getY()-41+h).
danpost danpost

2015/6/6

#
Another thing that might need to be considered is the movement of these DamageField objects when the MrBoom object moves.
Gingervitis Gingervitis

2015/6/7

#
Thank you so much for the more efficient code but that does not correct the problem of the MrBoom not taking damage.
danpost danpost

2015/6/7

#
Gingervitis wrote...
Thank you so much for the more efficient code but that does not correct the problem of the MrBoom not taking damage.
First, I said that it (the damage method code I presented) was equivalent to what you had -- not that it is actually what you wanted. That is to say that changes may still be required to have the method work in the manner that you had intended. To test the taking of damage, comment out the entire 'act' method except the call to 'dealEnemyDamage', compile, drag an EnemyDamageField object over the MrBoom object (check their locations so that the field is (100, 100) to the lower right of the mrboom actor) and then click on the 'Act' button. Then, test the value of the healthbar to see if it decreased.
Gingervitis Gingervitis

2015/6/7

#
Nothing...
danpost danpost

2015/6/7

#
Does the healthbar decrease if you manually call the 'subtract' method on it enteing '1' for the parameter?
Gingervitis Gingervitis

2015/6/7

#
Yes. The MrBoom loses health if it is directly called in the act method.
danpost danpost

2015/6/7

#
Test it by changing your 'dealEnemyDamage' method to this: 
public void dealEnemyDamage()
{
    Actor edf = getOneObjectAtOffset(0, 0, EnemyDamageField.class);
    if (edf != null)
    {
        hp.subtract(1);
        getWorld().removeObject(edf);
    }
}
Gingervitis Gingervitis

2015/6/7

#
Still nothing.... At one point I did get it to subtract health but at that time it subtracted to much health, however, I do not remember what a did to get it to at least take damage..
Gingervitis Gingervitis

2015/6/7

#
The MrBoom lost health when I used the getObjectsAtOffset method, however, it loses health immediately once placed in the world.
danpost danpost

2015/6/7

#
Gingervitis wrote...
The MrBoom lost health when I used the getObjectsAtOffset method, however, it loses health immediately once placed in the world.
Please show what code you used. However, if the (100, 100) offset worked at some point, then you can replace the zeros in my last code post to one hundreds and try it then. Does the EnemyDamageField object have a visual image or is it transparent?
Gingervitis Gingervitis

2015/6/7

#
danpost wrote...
Does the EnemyDamageField object have a visual image or is it transparent?
The EnemyDamageField object does have a visual image. Once it works and there are no errors I will then make it transparent. I just set the EnemyDamageField to not remove itself from the world and it appears when it touches the MrBoom object it turns away from it.
Gingervitis Gingervitis

2015/6/8

#
My teacher suggested I use the 'isTouching' method and that made the MrBoom object take damage but I wish I knew what the code for the 'isTouching' method is to see what I did wrong.
danpost danpost

2015/6/8

#
The 'isTouching' method is basically this: 
public boolean isTouching(Class class)
{
    return ! getIntersectingObjects(class).isEmpty();
}
// or
public boolean isTouching(Class class)
{
    return getOneIntersectingObject(class) != null;
}
Now, this, which checks that any part of the image of the actor intersects any part of an image of an actor of the class given, is different from using 'getOneObjectAtOffset(x, y)', which checks whether the image of any actor of the given class intersects the given location point at (getX()+x, getY()+y).
Gingervitis Gingervitis

2015/6/8

#
Yes, so that means that the with the other code I had, the EnemyDamageField was never actually touching the MrBoom object, right?
There are more replies on the next page.
1
2
3