"Pull" an object as well as push it

[Kes]

I am posting this in the general support section, rather than script support, as I am really hoping there is a non-script solution.

I know how to make an object move away from the player as if it were being pushed.  However, I would also like the same object to be capable of being pulled backwards because e.g. it gets pushed up against a wall, and then is immovable.

The only way I've seen this done is to hold down shift and hit the action button - but that looks to me like it might be some sort of key binding script, though maybe I'm completely wrong.

Does anyone have any tips on how to go about this?

Thanks

 

[Silent Darkness]

Say, shouldn't this be in Game Mechanics Design? Or script requests, or something? Support is for bugs and glitches and stuff.

And, i'm not really sure. Likely some sort of script call, I imagine.

 

[Galenmereth]

This works very well as a starting point; you'd have to add the other directions, of course

 

[Uzuki]

Well there is a way, although a tad bit cumbersome.

I find it easier to have a button be pressed while the player is pushing the block. I usually use the "S" key. Make a conditional branch that will check if the player is pressing the "S" key. Make more conditional branches inside the first that will register if the player is pressing up, down, left, or right. In each of those make a Move route that will turn on the player's Direction Fix (Be sure to un-check the wait box of course). Now make another move route for the block that will move towards the player when the first two conditional branches are meet. The third move route will turn off the Directional Fix for the player. Now just put all these move routes within all of the direction conditional branches.

EDIT: Darnnit I've been Ninja'ed!

 

[Cadh20000]

I just made a "choice" of push, pull, or neither. Though Uzuki's solution sounds like it would be easier on the player.

Spoiler

 

[GrandmaDeb]

Galenmerth remembered to move the player, I think.....


http://www.rpgmakervx.net/index.php?s=8385ce6a54465577ca442f9ab8cf2a54&showtopic=1817&view=findpost&p=25796

 

[Kes]

Thanks everyone.  I'll try them out when I get home this evening  and let you know what happens.

I think I shall probably use the one GrandmaDeb linked to as it uses the 'Shift' key - other solutions (use the C or the S) will be confusing for people who have a non-English language keyboard - that C or S could be anywhere!

 

[Galenmereth]

I think I shall probably use the one GrandmaDeb linked to as it uses the 'Shift' key - other solutions (use the C or the S) will be confusing for people who have a non-English language keyboard - that C or S could be anywhere!

Shift is called different things in different languages, however. Also, C is the action button in Ace; by default it's both Z and Enter However, my solution has a problem I'm trying to solve; if you back up into a wall while pulling an object, you'll get stuck if you try to pull into the wall. You won't move into the wall, but due to how move events work, the objects gets stuck in your position. The alternative is to wait for the player to move, then the object, and have a skip check on both, but that looks... weird. I'm trying different things to see if there's a non-script solution to this. But it's not looking to good right now :/

Edit: I changed it so that the player moves first, then the object (the image is updated). This still doesn't look too good; I'd prefer the object to move in tandem with the player, but then the problem described above occurs. Going to look at this some more later.

 

[GrandmaDeb]

With Ace's new features (I am thinking of regions) it seems that one should be able to set up a region in which pulling works (or into which pulling succeeds)


And ***hint, hint*** I don't think there is a "how to push and pull a boulder" tut yet. =]

 

[Uzuki]

Shift is called different things in different languages, however. Also, C is the action button in Ace; by default it's both Z and Enter However, my solution has a problem I'm trying to solve; if you back up into a wall while pulling an object, you'll get stuck if you try to pull into the wall. You won't move into the wall, but due to how move events work, the objects gets stuck in your position. The alternative is to wait for the player to move, then the object, and have a skip check on both, but that looks... weird. I'm trying different things to see if there's a non-script solution to this. But it's not looking to good right now :/

Edit: I changed it so that the player moves first, then the object (the image is updated). This still doesn't look too good; I'd prefer the object to move in tandem with the player, but then the problem described above occurs. Going to look at this some more later.

Did you click the Ignore if can't move box?

 

[Galenmereth]

Did you click the Ignore if can't move box?

Yes, but then you can't move the object while moving the player, as they need to temporarily occupy the same space.

 

[Shaz]

Say, shouldn't this be in Game Mechanics Design? Or script requests, or something? Support is for bugs and glitches and stuff.

Since the OP is asking for a NON script solution, no it shouldn't be in script requests.


Game mechanics design is for discussing ideas about game mechanics, not their implementation.


There is a bugs and glitches thread for bugs with the engine.


Ace Support is for "how do I do <something> in Ace without using scripts".


So it was posted in exactly the right place.


You COULD set it up with a conditional branch with a script to see if the boulder CAN move away from the player, and if it can, do so; if it can't make the player step back and make the boulder move towards the player. That way there would be no choices for the player to make, and they wouldn't have to hold down a key to tell it to move in the opposite direction. It would just move away as the first preference, and if it can't will move towards the player.

 

[Galenmereth]

So I implemented GrandmaDeb's idea of using regions (thank you!), and here's the solution:

The rest of the event page:

• $game_switches[2] <– 2 is the Switch you wish to store the region value of where the boulder will move to
• $game_map.region_id(@x,@y) == 1 <– 1 is the region id you wish to check for
• if @d == 4 <– This checks if the direction the player is facing is left
• if @d == 6 <– This checks if the direction the player is facing is right

Using this, an object can only be dragged into or showed 1 block out of regions painted with region 1 in the map editor. So you'd paint the floor 1 tile away from the wall with region 1 in this case, and voila; the object can be pushed and pulled around with this event. With this method, you can remove the "Skip If Cannot Move" from the object, since you can make sure a player can't drag n object "into" a wall. And with that unchecked, the object now moves as if dragged/pulled by the player.Edit: A problem with this approach: If there are events anywhere where you can move the event (like other movable objects), this breaks. To solve this, I have to check for the existence of other events at the new xy coords, and when I sat down to do this, I figured I might as well create a full-blown solution that doesn't require any region ids at all! But that becomes somewhat of a larger event page, so I went ahead and created a new tutorial post with an explanation, screenshots, and a downloadable demo. You can find it here: http://forums.rpgmakerweb.com/index.php?/topic/27322-intermediate-how-to-make-pushable-and-pullable-objects/

 

[Kes]

You COULD set it up with a conditional branch with a script to see if the boulder CAN move away from the player, and if it can, do so; if it can't make the player step back and make the boulder move towards the player. That way there would be no choices for the player to make, and they wouldn't have to hold down a key to tell it to move in the opposite direction. It would just move away as the first preference, and if it can't will move towards the player.

What would be the script call to check if the boulder can move away from the player?

 

[Shaz]

Try this

e = $game_map.events[@event_id]; e.passable?(e.x, e.y, $game_player.direction)

So your full event command would be this:

Conditional Branch: Script: e = $game_map.events[@event_id]; e.passable?(e.x, e.y, $game_player.direction)  Set Move Route: This event                : Move away from PlayerElse  Set Move Route: Player                : 1 Step Backward  Set Move Route: This event                : Move toward Player

with whatever waiting you want to have in there (if any)

 

[Kes]

Tried it out and got the following error message:

Script 'Game Interpreter' line 450: NoMethodError occurred

undefined method 'x' for nil:NilClass

For the script call I wrote it with the event id first as [@Rock] and then as [@event_Rock].  Both gave the same error message

Is it how I'm identifying the event to move (which, obviously, I've called Rock) or something else which is the problem?

 

[Shaz]

No. Two things wrong there.


Rock is the NAME of the event, not its id. If your event was originally called EV001, then the event's id is 1. If your event was EV005, the id is 5.


But you don't even need to substitute. If the rock is the event you're entering the commands on, then type in @event_id exactly like that - don't substitute anything. That means you can copy and paste the same event 15 times over and you won't have to edit the commands to change the event id. @event_id is used by Game_Interpreter to say "the event this command is running from".


So type it EXACTLY as I've got it there. Don't change ANYTHING.

 

[Kes]

That works great.  Thanks - I was trying to be too clever!

Other than putting in several 'Step Backwards', is there any way to account for followers?  I suppose I could try and find a story reason for followers to be turned off, but I was wondering if there was an alternative?

 

[Shaz]

Put this into a script call:

$game_player.followers.reverse.each {|actor| actor.move_backward }

Or you can also put this into the move route for the player (so it will do the followers' moves before the player's move):

Set Move Route: Player              : Script: $game_player.followers.reverse.each {|actor| actor.move_backward }              : One step Backward

I don't think it really makes a difference either way

 

[Kes]

The first option gives the error message:

Script 'Game_Interpreter' line 1411: NoMethodError occurred

undefined method 'reverse' for #<Game_Followers:0x96216ec>

The second option gives the error message:

Script 'Game_Character' line 180: NoMethodError occurred

undefine method 'reverse' for #<Game_Follwers:0x9600cf8>