This is my first post, I think, so I'm sorry if this has been covered before but I looked and couldn't find anything that inspired a good solution. want I'm looking for is that when the player object gets to close to a monster it triggers the monster to start moving. What is happening now is the when that the player get close to the last monster they all start moving, and not until then. I know this should be pretty simple but I guess I just don't know how to do it. Thanks for looking and any help with be great.
I remember being told that if you switch the position with the player and the enemy in the code the object focus is able to focus per enemy and not as a group.
Someone will surely be able to explain that better.
Personally, I believe that using a behavior may be easier than groups for this as spread values are not needed, and it will (probably) be easier to understand and much shorter.
I would do this.
Behavior:
Always Set value "Distance" of object to abs(enemy X Position - Player X Position)
Value "Distance" of object <= 128
- Movement Code
Whats cool about this is that its also easier to give each enemy its own sight-range by creating another alterable value for each individual enemy. We'll call it "Sight" and you will change it to how many pixels you wan't the enemy to be able to "see." - In this case - 128. Just make sure that "Sight" is the same alterable value for EVERY enemy (IE: Alterable Value D) so that it can reference it properly.
Behavior:
Always
Set value "Distance" of object to abs(enemy X Position - Player X Position)
Value "Distance" of object <= Value "Sight" of object
- Movement Code
If you want to get really fancy you could use the distance formula, which will get the distance between two objects in any given direction, rather than only X distance.
Always
Set value "Distance" of object to Sqr((X( "Player" )-X( "Enemy" ))*(X( "Player" )-X( "Enemy" ))+(Y( "Player" )-Y( "Enemy" ))*(Y( "Player" )-Y( "Enemy" )))
Value "Distance" of object <= Value "Sight" of object
- Movement Code
I suck at reading formulas. You can probably find more info in articles around here, but heres the distance formula without the values already plugged in:
sqr((X1-X2)*(X1-X2)+(Y1-Y2)*(Y1-Y2))
This isn't necessary, but you can make the distance formula easier to read by using two more alterable values:
Always
Set Value "X Dist" of Object to (Player X Position - Enemy X Position) * (Player X Position - Enemy X Position)
Set Value "Y Dist" of Object to (Player Y Position - Enemy Y Position) * (Player Y Position - Enemy Y Position)
Set Value "Distance" of Object to sqr(X Dist + Y Dist)
Firstly, you should be spreading the value *before* you start the fastloop. You should also start the fastloop on a new line (MMF2 has some bugs, and this just makes it more stable).
Secondly, you shouldn't even be using a fastloop for this to begin with.
Now, the reason your code doesn't work: you *must not* use "compare two general values" if you have more than one instance of an object, as it will *always* retrieve the value from the newest instance.
eg.
On line 31, you have:
-> X("Player")-X("Baddie") < 0
-> X("Player")-X("Baddie") > -128
You *could* have said:
-> X Position of Baddie > X("Player")
-> X Position of Baddie < X("Player") + 128
Note that you *must* compare the X position of the Baddie to the X position of the Player - not the other way around.
The method Gamester suggested (using an intermediate value) is the best way to go, and that's what you'll end up using most of the time - especially if your conditions are more complex.
However, the code doesn't need to be, and *should not* be in a behavior. That only makes it harder to keep track of your code, prevents you using the event list editor, and takes away control over exactly when to execute the event. I'd strongly recommend you avoid behaviours altogether.
@Gamester: Please don't use the code tag. The line-spacing is ridiculous.
I have no trouble keeping track of behaviors, as I keep my alterable values and strings true across all enemies and mainly use it for things such as damage addition subtraction etc. The only downside IMO is the fact that you cannot reference a group inside a behavior. Groups also have some selection issues that have to be dealt with with work arounds so I try to avoid them in certain scenarios.
Advertisement
Post Reply
