10 replies to this topic

[exnitrous]

I made a platformer game and there is for some issue an error with the attacking. My enemy is supposed to bounce back when hit, but it simply passes through the player and freezes. Wat should i do?
http://www.mediafire...bg5966byjbd6svt
you can see the code idk what the issue is.

[icymx]

If you post your code people will be much more likely to help you. Sorry, but I'm not downloading that.

[rude guss]

If you post your code people will be much more likely to help you. Sorry, but I'm not downloading that.

Don't listen to this guy. First off, this guy makes the stupid assumption that everyone uses GML. That is not the case. Posting D&D is not easy and is not very useful for getting help. Also most Novice users do NOT know where the problem lies, and end up posting useless code, which could have been solved infinity faster if they had just posted the source file.

Now on to the problem. I have NO idea on what is going on!! I changed the code "x+=40" to "x=0" and that worked fine. But your code doesn't work. GG

Edited by rude guss, 01 March 2012 - 09:18 AM.

[BattleRifle BR55]

Don't listen to this guy. First off, this guy makes the stupid assumption that everyone uses GML.

Saying "code" is usually taken as "what you did" - however, if you want to be literal, the OP actually uses the word "code", and so someone responding without downloading the file will simply reply with that word.

Also most Novice users do NOT know where the problem lies, and end up posting useless code, which could have been solved infinity faster if they had just posted the source file.

Problem is, nobody wants to do anyone else's work. I personally don't want to download files. If they don't know where the problem lies, why do I have to go and dig around for it? And if they don't know where their problem is in the first place, then what novices need to do is to look at everything they did, try to further understand it, and experiment in changing/removing code until they find their problem. If you code things that spread across a large field and don't know where to begin looking for problems when they crop up, hell, that's a different problem in and of itself to begin with. Part of learning how to code something is learning how to manage the way it works by itself, and with other things.

This is why it's encouraged to try to fix your own problems, and when you're really stumped on something, you post what you did, because you'll have a better understanding of where the problem lies than you would have without doing so, and then we can pinpoint a faster solution. Most that just throw a file do so without having really checked what they did. Go look at some topics that follow that pattern, and see how simple the solution usually is - and I don't mean simple for a seasoned veteran.

The OP says that his problem is with the way a character responds to being attacked. So we have a starting point - a potential collision event. Therefore, we don't need a file of menus and music such.

Now on to the problem. I have NO idea on what is going on!! I changed the code "x+=40" to "x=0" and that worked fine. But your code doesn't work. GG

I'm not going to assume what you mean by the first part, but don't you see how this looks? You say that it's easier to just look at the file, but yet turn around and say that you're lost?


To the OP - I ain't ragging on you specifically, just stating things.

[rude guss]

Problem is, nobody wants to do anyone else's work. I personally don't want to download files. If they don't know where the problem lies, why do I have to go and dig around for it? And if they don't know where their problem is in the first place, then what novices need to do is to look at everything they did, try to further understand it, and experiment in changing/removing code until they find their problem. If you code things that spread across a large field and don't know where to begin looking for problems when they crop up, hell, that's a different problem in and of itself to begin with. Part of learning how to code something is learning how to manage the way it works by itself, and with other things.

I can totally see where you are coming from, (I've seen plenty of 'can someone do this for me' posts), but sometime a 'different' pair of eyes may be needed to spot an error. Some people learn form mistakes, but how do you learn if you never realise these mistakes?? To be fair, the poster asking for help posted way more information than what most other novices do. Though it may have been a bit aggressive, I was just stating that the poster was not wrong to post the source file, he didn't know what was causing the problem, so posting code here would have been of no help and just messy - since he/she uses a combination of D&D and GML.

The OP says that his problem is with the way a character responds to being attacked. So we have a starting point - a potential collision event. Therefore, we don't need a file of menus and music such.

Agreed, I myself would not download a 10mg+ file as well, but if you take a quick look the download size is less than 100kbs. Though we do have a starting point, some problems are not so easily solved as the code may have dependencies elsewhere. For the benefit of everyone here, I will post the collision event code:

//collision event (of enemy) with player
if global.attacking = 1
{
    if other.x < x
    {
        x += 40
    }
    else
    {
        x -= 40
    }
    if other.y < y
    {
        y += 5
    }
    else
    {
        y -= 5
    }
}

Now do you see why telling a novice to post their code may be redundant? You may have to look at the whole file anyway in the end. Hopefully someone else can solve the posters problem from looking at this code. Before you ask, I did check if the global.attacking variable, and it does change as the poster intended it to.

Now on to the problem. I have NO idea on what is going on!! I changed the code "x+=40" to "x=0" and that worked fine. But your code doesn't work. GG

I'm not going to assume what you mean by the first part, but don't you see how this looks? You say that it's easier to just look at the file, but yet turn around and say that you're lost?

I think you misunderstood (my fault due to my poor writing) - I was not talking about how I did't understand what his code was doing. I was confused as to why his code was not working. His code reacts when you move the object absolutely (eg. x = 50), but does NOT react when you move the object relatively (eg. x+= 50).

Something else I tried was deleting all the code in the collision event and writing "instance_destroy()". That worked, so next I removed that code and tried "x+=100". That did not work. Maybe someone can deduce the problem from my observations. If I had to guess, the poster uses a 'start moving in a direction' action - maybe this is conflicting with x and y positions. I would not know - I dont use D&D personally.

Edited by rude guss, 01 March 2012 - 11:18 AM.

[BattleRifle BR55]

Of course, I completely agree with what you're saying. Probably because how much I've seen and commented on it as of late is why I feel so strongly about it, as usually people's hands type faster than their minds can keep up and then they have no idea what the heck is going wrong with their project and expect someone else to do the work for them. Again OP, not directly commenting on you. I also can't download Mediafire files anymore for some reason, which is a big reason why I ask people to post their code when they use that site.

Also with that last part, I tried to put as little emphasis on it as possible because I just wanted to point out how funny it looked after the rest of your post.

[torigara]

Sometimes it is recommended to post the object information of relevant objects. It will encourage more people to take a look rather than downloading a file.

Information about object: obj_muncher
Sprite: spr_muncher
Solid: true
Visible: true
Depth: 0
Persistent: false
Parent: 
Mask:

Some of you may immediately realize the potential problem at this point: a moving object is made solid. (For a note, the other object, obj_player is also solid.) So, people will advise to uncheck that "Solid" box of both objects. And the problem indeed has gone.

It is a bit harder to tell why it actually caused the problem. Well, let's keep reading on the rest of object information:

Spoiler

(snip)

Create Event:

set the sprite to spr_muncher with subimage 0.3 and speed 0.3
start moving in directions 000100000 with speed set to 1.5
Step Event:

set the gravity to 0.01 in direction 270
Collision Event with object obj_player:

execute code:

if global.attacking = 1
{
if other.x < x
{
x += 40
}
else
{
x -= 40
}
if other.y < y
{
y += 5
}
else
{
y -= 5
}
}

Collision Event with object obj_grass:

execute code:

move_contact_solid(direction,10) // move into contact with the solid
vspeed = 0 // stop vertical movement

That's all of the object information of the enemy. One piece to solve the puzzle is the fact that the gravity is never reset to 0. So, the object is continuously being pressed toward the floor. The same applies to the player. Other interesting part is that the player has a different amount of gravity.

Information about object: obj_player
(snip)

Create Event:

execute code:

global.attacking = 0;
gravity = 0.7;

This causes the enemy and player have different values of y even if they appear to be on the same floor. If you have a time to download the file and run it in the debug mode, you can see that obj_player.y is slightly smaller than obj_muncher.y. Now, do you recall this part of the code in the collision event?

...
if other.y < y
{
y += 5
}
...

Also remember that "solid" will do more thing than you thought. When a solid object is involved in a collision, the object does not only put back to the previous position before executing the collision event. It can also get put back after the event.

When the other object is solid, the instance is placed back at its previous place (before the collision occurs). Then the event is executed. Finally, the instance is moved to its new position. So if the event e.g. reverses the direction of motion, the instance bounces against the wall without stopping. If there is still a collision, the instance is kept at its previous place. So it effectively stops moving.

Since other.y is smaller than y, the code shown above puts the enemy at y+5, burying it into the floor. After the collision event is over, Game Maker checks whether its new position is collision free. As it is now inside a floor, Game Maker will put it back to xprevious and yprevious again, cancelling changes made to x and y. That is why the enemy didn't get knocked back.

Edited by torigara, 02 March 2012 - 03:24 AM.

[icymx]

Sorry if I came across as a bit of an a**hole, I do that sometimes :/
But anyway, you should post your code as a courtesy to the members that are going to help you. I must admit I'm not one of the best with GML and have embarrassed myself on several occasions, by trying to help but actually making things worse...

Anyway, I didn't mean to be rude, and I hope you can solve your problem

Edited by icymx, 02 March 2012 - 06:49 AM.

[exnitrous]

k thanks guys

[exnitrous]

thanks i got it to work, but now i wish to know if i have a enemy, and he aproches me, he stops when i am close, and continues when i back up
ex:
me:-
enemy:{
_{ duel goes down
_ {
_ {
_ { enemy follows and stops when he closens.
I also want the sprite to change when he leaves or enters.
How do i do it?

[BattleRifle BR55]

Using one of the distance-checking functions, check to see if his distance is greater than the one you want him to stop at. If he is farther from that range, move him.