It may be (in fact probably is) a very simple thing, but I can't get the mouse to work with shopkeepers.
I made all shopkeepers "behind" their counters and used the counter passability. So using the keyboard, I can click on the other side of the counter and then go into the shop.
Unfortunately this does not work with the mouse, because if you click on the desk the mouse does not detect anything and if you click on the shopkeeper itself the mouse does not detect it either since it's on the other side of the desk..
Is this a limitation of the script, or do I need to set up shopkeepers slightly differently for use with a mouse, or just simply put the 'shop processing' event on the counter instead of on the shop keeper, or...?
Are you using the offset variables? If the shopkeep is behind a one-tile-wide counter at the top of the map, for instance, the proper query to the script would be:
<mouse talk 0 2 Shopkeeper>
That command tells the system to move the player to two tiles below that event and then run the event's script. The script doesn't 'see' through solid walls/tiles/etc. for pathfinding so you have to give it a location that it can get to (e.g. right next to the edge of the counter).
I have that problem as well, and I think it's because of the way counters are drawn (they take up 2 tiles vertically because the bottom few pixels are drawn on the tile below). That's on my list of things to investigate.
You can get around it (and I do) by following Firgof's suggestion, and adding an offset to the shopkeeper to direct the player to go 2 tiles below the event.
Back again. I hope this doesn't count as a double post because it is about a totally different matter.
This time I don't think it's me. The problem is in a project which is now complete and being tested for me. I developed it before putting in a mouse script, but the tester has, obviously, started the play through with the script enabled.
It seems that the script does not work with events that are "below character" and "player touch", because the characters go through it without the event ever having the chance to do what it is supposed to do. For example, on stairs that I don't want the player to go up, or a path that I don't want the player to go down yet, I have the standard 'blocking' event, that is, a dialog box and a move event pushing the characters back down. Using the arrow buttons on the keyboard the events work as they are supposed to, but with a mouse it is as if the event is not there.
Is there some fiendishly cunning way that I am supposed to set up the event so that this does not happen, or is this something to do with the script itself?
Sorry if this is yet another noob question with the answer staring me in the face. I thought I was beginning to get to grips with scripts, but the last few days show me that I haven't.
Is your event set to Player Touch? Try adding the following script call right at the start of the event:
Call Script: $game_player.clear_path
If that doesn't work, can you start a new thread in the RGSSx Script Support forum, add a link back to this thread, and include a screenshot of your map highlighting where the event is, and a screenshot of your event (the entire window, not just the command list), and I'll try and reproduce the issue and get a solution for you.
Yes, the events concerned are all set to Player Touch.
Adding this line seems to work, though going through an otherwise completed game to find every single instance is going to be a nightmare. For the future, will I have to do this for every 'blocking' event, or is there a global way of doing this?
Show me your event. When you set a move route, the path SHOULD be cancelled, and the move route should take over. If it's not doing this, then I'm thinking you must have a wait, or be showing some text, or something that has a bit of a delay before the move route starts.
I COULD give you a quick fix that will clear the move route whenever a player touch, event touch or action button event is launched. But that might also make the player stop moving in the middle of a path when you don't really want them to.
You've got my Extract Event script, don't you? That might help you find them all more easily.
Here is an example, without the new line. As you can see, there is nothing fancy about it, just a bit of text and a set route move. When set up like this, if you approach this tile using the arrow keys it stops the player in their tracks and sends them back one tile. Using the mouse, if you click beyond this tile, the player just sails over it as if it were not there. With the new line, it stops the player as expected.
re-reading your post, yes, I do have the text first, but logically the party should be stopped and then the move happens, It makes no sense for them to turn back and then be told that they can't go there,
I don't understand the third option, which I assume means some change in the script itself. If that is a global solution, then it is the one I would prefer because it is so easy (if you are me) to sometimes forget to put in the extra command.
The second option looks as if it is putting in the extra line as a standard part of setting up any such event, whilst the first looks like going back and correcting all previous instances. Insofar as I could easily overlook something, I would prefer to do this as a last resort.
I still have to sort out those events which involve jumping and are presently set up with the conditional 'The left/right button is being pressed'. The consequences, unfortunately, of never ever playing with a mouse myself is that I'm only now having to learn how mouse players do things.
The second and third options are both script changes. Only the first one would require any changes to your events.
Which one you choose depends on what you want to happen when the player walks over a Player Touch event that does NOT have a move route. Do you want the mouse movement to be cancelled altogether, or just to be paused while a message is displaying, and then to resume (unless there's a move route immediately after the message)?
Well, for example, I've used your region event script quite a bit, so when the player walks on a tile set up with that, I want them to stop while the common event is being called up. Having tested it, I find at the moment that the common event is called up, but the player keeps on walking.
Long story short, if it's below the player and player touch (either event or region) I want the mouse movement paused until the first command - whatever it is - is carried out.
As it is, the player would keep walking even if you used an event there set to Event Touch. In your common event, just add a $game_player.clear_path as the first command.
I won't be modifying the mouse script to work in conjunction with the region event script. Your requirements may be completely different to someone else's - someone else may WANT the player to keep walking. YOU may want the player to keep walking sometimes.
To be honest, if I want player movement halted on a Player Touch event that's going to show text before a move route, I will add a clear_path script call at the start of the event. I know you don't want to go through and modify all your events, but that's one of the decisions you must make before you add a script half way through development. If I made a change to the mouse script that requires me to go back and change events, I would consider whether the script change is worth the effort, and if it is, I'd go back and change events.
There is no easy way out, because the rules you set are very unlikely to apply in all cases. I could change the script to do what you just said you wanted, but I can guarantee you the first time someone plays with those changes applied, you will ask me to change it further because they've found a situation where what you said isn't the desired behaviour.
If you have the event extract script, just do a search for a set move route with the player. You'll need to find one first to get the correct format. Then just search for that, and hopefully your event maps and names, and what comes before/after in the list will make it easy for you to see which ones you need to change.
Back again - sorry about this, but I am so confused about what on earth is happening. Here is a video to illustrate. What you are seeing is this:
1) General movement. the sprite ends up to the right of where the cursor is pointing.
2) Select sword, goes to it, but won't interact. Clicking on the sword again causes the sprite to move right. Won't interact until finally click one tile to the left of the sword.
3) Select General. Instead of going direct, goes round to the right.
Clicking on the General does not lead to interaction.
Then try from the left. Sprite goes there, but when the General is clicked, instead of interacting, goes all the way round to the right.
Finally get sprite next to the General. When click on General, sprite turns to the right.
Eventually get the interaction when click to the left of the General.
Ah, technical hitch. I'm getting the message that I can't upload this type of file (.avi). I'll leave the description above, and here instead is a screen shot of the position of the cursor to get the General to begin his dialogue.
Unfortunately, that's not very helpful. It could be a glitch caused by this script interacting with another script, it could be the way you've got your events set up. Do you have your map set to scroll either horizontally or vertically? That could (probably would) cause issues.
All I can do is either get you to load a picture of your map in the editor so I can see where the events are (I need the editor view, not the playtest view), and screenshots of the events with issues. If that doesn't reveal anything, I'd need to look at your project itself to see if it's a conflict between scripts.
Since you are having so many issues, I will ask you to start a new thread rather than fill up this one with pages and pages of your issues
I really get the feeling I should be doing regular YouTube videos whenever I make something cool in my game, instead of waiting for massive changes. But not going to lie... I always feel like it's never quite enough to merit an update, until it's a drastic change.