IKSB

Bump.

Does anyone know anything about the GMS physics? Because whenever I ask about it, nobody seems to have any answers.

Could you maybe have some sort of border object and then check where the line intersects with the object? In GMS you could simply have an object of a standard size and then in the actual editor drag-stretch it to the custom size of the room edge.

Why do the objects need to destroy themselves? Can't you condense into one object with both functions built in? Whenever you add in this object switching stuff, which is tempting in the beginning of programming, things can get really messy. So I would first condense this into one object and see if the problem persists.

With the current code you have, what happens when you scroll? Does it scroll one way and not the other? Does it crash? Does nothing happen? Know how the game is reacting to the issue you have is important information if you want someone to be able to give you a comprehensive answer.

Actually, having the inventory as a separate object is a bad idea. I would instead have the inventory toggle as a variable in your main all-powerful controlling object. So then when you press I, it simply:

inventory = !inventory //there is an exclamation point there, I swear.

Then in whatever object draws the HUD, have it check inventory toggle variable and, if it is true, have it draw the inventory on the screen and if false, then not. It's actually fairly straight forward.

When I first started GM I also did the whole instance-switching thing, but that kind of coding introduces problems of its own that are just not necessary to deal with. So I would scrap that system and try to work through it a different way:

Have some sort of variable that defines the awareness of the monster. Call it aware, for simplicity's sake. So then aware would have three states:

aware = "unaware" //does not know the player is nearby
aware = "aware" //knows the player is nearby and where the player is
aware = "searching" //knows the player is near, but isn't sure where

So the monster by default begins at aware = "unaware". Then, when it sees the player:

if aware != "aware" {
  aware = "aware";
  alarm[0] = -1 //you'll see why this is here later
} //if aware is anything but aware, set it to aware. Actually simple. Aware doesn't even look like a word anymore...

Then, when the player is out of sight:

if aware = "aware" {
  aware = "searching"
  alarm[0] = [amount of time you want it searching];
}

So then, in alarm[0] you have it say:

aware = "unaware"


Then, in the step event, you simply have each AI for the movement in a particular state of awareness begin with:

if aware = "searching" then { [amazing code] }


So this solves the AI thinking process. Pathfinding is a completely different story. I would advise for that just starting with the built in pathfinding functions. They are a little screwy, but they work for the most part. So then you have it say that, if it is aware and it can't see the player, it [pathfinding function] till it can see the player. If that makes sense.