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

2018/1/8

Removing an item that was never touched

Echarch11 Echarch11

2018/1/8

#
Hey, I am trying to remove an item that was never touched. However it is supposed to only be removed when the character touches the badguy. For example when the character kills the badguy (removing him) I want another actor to be removed which is supposed to act as his vision cone. Thanks any help is great
danpost danpost

2018/1/8

#
If each vision cone object "knew" which actor it was used for, it could ask "if the actor I am used for is not in the world, remove self".
xbLank xbLank

2018/1/10

#
Say you are adding your Objects into the world like this: 1. Add Object(badguy) //index 0 (badguy.class) 2. Add Object(vision cone) //index 0 (visionCone.class) 3. Add Object(badguy) //index 1 (badguy.class) 4.Add Object(vision cone) //index 1(visionCone.class) and so on.. You realize something dont you? If a badguy is touched you ask for his index moments before his death and remove a vision cone with that exact same index. Because you know they belong to each other since you add them one by one.
public class badguy extends Actor
{
	public void act()
	{
		if(isTouching(Bullet.class)) //dead
		{
			visionCone cone = getWorld().getObjects(visionCone.class).get(getWorld().getObjects(badguy.class).indexOf(this));
			getWorld().removeObject(cone);
			getWorld().removeObject(this);
		}
	}
}
I didn't test this before so there might be some problems.
danpost danpost

2018/1/10

#
@일리아스 Using the index of a List returned from 'getWorld' will not guarantee success in selecting the correct object from the list. You are using an undocumented set-up of the list which could change. There is a much easier way to handle the cones anyway. Move the cone class into the badguy class (as an inner class). All cones created will then automatically belong to the badguy object that created it. As another benefit, the cone is automatically given a reference to the badguy it belongs to. The badguy will need a reference to the cone it creates, however, and add it into the world when it is added to the world:
public class badguy extends Actor
{
    private Cone cone = new Cone(); // creating cone

    protected void addedToWorld(World world)
    {
        world.addObject(cone, getX(), getY()); // adding cone to world
    }

    // other codes for badguy

    private class Cone extends Actor
    {
        public void act()
        {
            if (badguy.this.getWorld() == null)
                getWorld().removeObject(this); // removing cone from world
        }
        
        // other codes for Cone
    }
}
xbLank xbLank

2018/1/10

#
I did the logic and im quite sure it works. I know the index can change once you remove an item from the list but since you remove the same index from each list you will end up with the exact same order. It should work. In that case I think that my solution is simpler for the OP to edit.
danpost danpost

2018/1/10

#
일리아스 wrote...
I did the logic and im quite sure it works.
I never said that it does not work. I am not arguing that. I am saying that it may not always be the case that it works (however, in this particular instance, it is quite improbable that it will change). You should not rely on the list generated by a World objects for its actors to be ordered a specific way unless it is documented to be that way. Better is to create a list of your own that you know for certain will be in whatever order you allow; or, to do something similar to what I suggested above (as far as having each cone keep a reference to its badguy object and removing itself like in the code I provided above).
xbLank xbLank

2018/1/11

#
This is very true. Let's call it a poor ghetto fix for a school's project. Depending on the OP's current code structure he should choose whether or not my answer is simpler to implement althought there might be a super tiny little chance that it will fail at one point.
davmac davmac

2018/1/11

#
일리아스 wrote...
I did the logic and im quite sure it works.
It should work with the current version of Greenfoot, provided you haven't called the World's setActorOrder(...) or setPaintOrder(...) methods. If you have used either of those methods (with an ordering), I think it won't work. (And as you've discussed already, it might not work in future Greenfoot versions).
You need to login to post a reply.