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

2016/9/18

Random timed movement, ranged player detection and camera tracking
3
4
5
6
7
8
Parte Parte

2016/9/29

#
Super_Hippo wrote...
Ah, I know why. Hm, you could try to remove all 'return' in the act method.
Removing all the return; lines in the act method does not do anything.
Super_Hippo Super_Hippo

2016/9/29

#
Hm, I thought the code I wanted you to add at the end of the act method was not reached because the returns would exit the method. How does it look now?
danpost danpost

2016/9/29

#
Parte wrote...
Sorry for the late reply. Here it is http://www.greenfoot.org/scenarios/17690
We cannot look at the code the way you uploaded it. You need to upload it again. This time, check the 'Publish source code' checkbox so that we can download the scenario and look at the code.
Parte Parte

2016/9/29

#
danpost wrote...
Parte wrote...
Sorry for the late reply. Here it is http://www.greenfoot.org/scenarios/17690
We cannot look at the code the way you uploaded it. You need to upload it again. This time, check the 'Publish source code' checkbox so that we can download the scenario and look at the code.
Sorry about that, here it is : Scenario
danpost danpost

2016/9/29

#
In the 'persue' method of the Enemy_Test3 class, remove the 'getX/getY' line before the 'setLocation' line and use the 'getX/getY' values gotten from the first line of the method in the 'setLocation' line.
Parte Parte

2016/9/29

#
danpost wrote...
In the 'persue' method of the Enemy_Test3 class, remove the 'getX/getY' line before the 'setLocation' line and use the 'getX/getY' values gotten from the first line of the method in the 'setLocation' line.
Thanks! That's half the problem solved, they don't run through the wall class now. However they still "pursue" the Player when there is more than one of them in the world and when they have line of sight obstructed.
danpost danpost

2016/9/29

#
'800' is quite a distance -- even in a world size as large as yours (which is a bit extreme; especially without some type of scrolling). With that distance, pretty much if an enemy appears within the scenario viewer along with the player, it will almost always be close enough to cause a pursuit.
Parte Parte

2016/9/29

#
danpost wrote...
'800' is quite a distance -- even in a world size as large as yours (which is a bit extreme; especially without some type of scrolling). With that distance, pretty much if an enemy appears within the scenario viewer along with the player, it will almost always be close enough to cause a pursuit.
I am happy with the distance chosen however I do plan to implement camera tracking/ make my scenario a scrolling world however I am not sure how I am going to do that with my scenario. Also with the enemy classes being able to pursue the player if there are 2 or more enemy_test3 classes in the world even if there is an obstruction in their line of sight, how is this able to be fixed or do I have to just make individual enemy classes and only have 1 of each in the world (I suggest this because this issue does not occur when there is only one object of the class in the world).
danpost danpost

2016/9/29

#
Parte wrote...
I am happy with the distance chosen however I do plan to implement camera tracking/ make my scenario a scrolling world however I am not sure how I am going to do that with my scenario.
Well, once you implement camera tracking, the enemies will start shooting at the player long before they show up within the viewer. Even at a height of 800 for the viewer window, the enemy would have to be under 400 away to be seen. So, if they shoot at from 800 away, that gives no chance for the player at all.
with the enemy classes being able to pursue the player if there are 2 or more enemy_test3 classes in the world even if there is an obstruction in their line of sight, how is this able to be fixed or do I have to just make individual enemy classes and only have 1 of each in the world (I suggest this because this issue does not occur when there is only one object of the class in the world).
Nothing is causing the enemies to act differently when more than one is in the world. They each act individually without regard for the others. There is nothing in the code that would have one effect another and I do not see that kind of behavior when I run the scenario.
Parte Parte

2016/9/29

#
danpost wrote...
Parte wrote...
I am happy with the distance chosen however I do plan to implement camera tracking/ make my scenario a scrolling world however I am not sure how I am going to do that with my scenario.
Well, once you implement camera tracking, the enemies will start shooting at the player long before they show up within the viewer. Even at a height of 800 for the viewer window, the enemy would have to be under 400 away to be seen. So, if they shoot at from 800 away, that gives no chance for the player at all.
with the enemy classes being able to pursue the player if there are 2 or more enemy_test3 classes in the world even if there is an obstruction in their line of sight, how is this able to be fixed or do I have to just make individual enemy classes and only have 1 of each in the world (I suggest this because this issue does not occur when there is only one object of the class in the world).
Nothing is causing the enemies to act differently when more than one is in the world. They each act individually without regard for the others. There is nothing in the code that would have one effect another and I do not see that kind of behavior when I run the scenario.
I will mess around with the range values some more later down the road. Also, are there any applicable camera tracking methods/examples that would work well for my current scenario? Have you tried having two or more Enemy_Test3 classes within range and having an obstructed view? Because they are definitely pursuing and continuing random movement at the same time (well probably not the same time but instead switching back and forth between the two methods). I recommend boxing 2 Enemy_Test3 classes in a corner with the Wall classes and then proceeding to move around them on the outside of the walls while being within range. You should definitely be able to see the issue then.
danpost danpost

2016/9/29

#
Parte wrote...
Have you tried having two or more Enemy_Test3 classes within range and having an obstructed view? Because they are definitely pursuing and continuing random movement at the same time (well probably not the same time but instead switching back and forth between the two methods). I recommend boxing 2 Enemy_Test3 classes in a corner with the Wall classes and then proceeding to move around them on the outside of the walls while being within range. You should definitely be able to see the issue then.
Maybe they are automatically going back into the chase state upon clearing the 'pursued' field because the player is still in range. That will have to be checked into.
are there any applicable camera tracking methods/examples that would work well for my current scenario?
You might try implementing my ImgScroll class that scrolls a larger background image (or to dimensions given it). I thought I had it in one of my scenarios on the site, but was unable to locate it. I will upload it with source once I find it (I know I have it somewhere). It should be just what you need.
danpost danpost

2016/9/29

#
I found it (it was not included in any of my collections, so I was not able to locate it easily). My Bee Quick (ImgScroll Demo) scenario has it.
Parte Parte

2016/9/30

#
danpost wrote...
I found it (it was not included in any of my collections, so I was not able to locate it easily). My Bee Quick (ImgScroll Demo) scenario has it.
What am I missing? Scenario stops as soon as I run it. (and yes I already have the ImgScroll class in my scenario). 
public class Worldbackground extends World
{
    public ImgScroll scroller;
    private Player_Test1 player_test1;
    
    /**
     * Sets Worldbackground's image size to be 3840 x 2160 with a cell size of 1.
     * prepare method is executed.
     */
    public Worldbackground()
    {    
        super(1920, 1080, 1, false); 
        prepare();
        
        scroller = new ImgScroll(this, new GreenfootImage("Worldbackground.jpg"), 3840, 2160);
       
    }
    
    /**
     * Speed of scenario is assigned to 65.
     * BgMusic class is assigned to play background music.
     * When "r" is pressed the World class will reload the Worldbackground class so that all World objects return to saved coordinates.
     */
    public void act()
    {
        Greenfoot.setSpeed(65);
        
        BgMusic.play();
        
        scroller.scroll(getWidth()/2-player_test1.getX(), getHeight()/2-player_test1.getY());

        if (Greenfoot.isKeyDown("r"))
        {
            Greenfoot.setWorld(new Worldbackground());
        }
    }
Console error: java.lang.NullPointerException at Worldbackground.act(Worldbackground.java:38) at greenfoot.core.Simulation.actWorld(Simulation.java:610) at greenfoot.core.Simulation.runOneLoop(Simulation.java:545) at greenfoot.core.Simulation.runContent(Simulation.java:221) at greenfoot.core.Simulation.run(Simulation.java:211)
danpost danpost

2016/9/30

#
Parte wrote...
What am I missing? Scenario stops as soon as I run it. (and yes I already have the ImgScroll class in my scenario).
It is probably that 'player_test1' in the prepare method is not being assigned properly. Make sure you are not creating a new variable, but referring to the field on that assignment line.
Parte Parte

2016/9/30

#
danpost wrote...
Parte wrote...
What am I missing? Scenario stops as soon as I run it. (and yes I already have the ImgScroll class in my scenario).
It is probably that 'player_test1' in the prepare method is not being assigned properly. Make sure you are not creating a new variable, but referring to the field on that assignment line.
This is the player in my prepare 
Player_Test1 player_test1 = new Player_Test1(movement_test21);
        addObject(player_test1,100,100);
This is the movement in my prepare 
Movement_Test2 movement_test21 = new Movement_Test2();
        addObject (movement_test21, 100, 100);
        int movement_test21X = movement_test21.getX();
Would it be better to have the camera tracking locked onto my Movement class instead of my Player class because the movement class is what moves the player while the player just sticks to the movement class. What should I do now?
There are more replies on the next page.
3
4
5
6
7
8