Amaranth's Super Simple Mouse System for Ace

[Andar]

Oh I meant, just have Chrome/Photoshop (100% guaranteed with photoshop) open and running in the background while playing the game. It tends to make Mouse Systems not work in RM for me.

I know that earlier versions of photoshop (and possibly even up-to-date-versions) had their own drivers to integrate grafic tablets into their controls - that might be the reason for this behaviour, even if those added tablet drivers are no longer needed with modern windows versions. Because in earlier windows, they had to modify standard windows drivers for the mouse to integrate those special checks for graphic tablets and graphic pens.

That mixup between input methods still causes problems with RM when installing tablet drivers which use legacy methods, but to change those problems all programs (including RM) and all drivers would have to be updated to use the modern input functions instead of the legacy functions...

 

[Firgof]

Shaz, here's the map scenes.  The first one shouldn't work.  The second one should.

https://dl.dropboxusercontent.com/u/80991744/TRON/Map001.rvdata2

https://dl.dropboxusercontent.com/u/80991744/TRON/Map002.rvdata2

 

[Shaz]

Firgof, I'm not seeing an issue. I had to remove the script call because I don't have the lantern stuff in Game_Map that it requires, but it works fine for me.


Is it a case that you have to click on the event a second time to actually get it to run? Or does it face the event, have a delay, and then the event runs (this is what I thought you were saying at first)?

 

[Firgof]

No, on the first map I just click on the lantern, the character walks up, and nothing happens no matter how long I wait.

Curious that you're not having the same issue on your end.  I ... have no idea why it's behaving differently between us?

It's like the event/map corrupted -- but only on my end.

 

[Shaz]

What if you move the mouse script to be above all other custom scripts? It ONLY happens with that one event? What if you copy the event and paste it to a new one, and interact with the new one?

 

[Firgof]

It's happening when no other scripts are present but the Mouse system.  Both copy-pasting the event and copy-pasting the pages of the event cause the same problem.  Creating a new event and inputting the data manually results in the same issue.  I've only been able to replicate it with that one event so far.

 

[Shaz]

If you walk up to it so you're directly beside, and click it, does it activate the event straight away?

 

[Firgof]

Unfortunately, no to that as well.  I can walk away, click and move to it and wait; I can walk up to it and click.  I can hold down control to ensure it's not getting hung on trying to find a path.  It just doesn't run that event no matter what I seem to do to it.  I even dumbed it down so that it was just <mouse touch Lantern> and show message: 123.  

Edit: It's almost like events in the map beyond an ID range of, say, 8 just don't run.

Edit 2: In this map, it takes two clicks to interact with most events on it.  The first click will just take you to beside the event.  When next to the event if you then click the event will run.  Perhaps it's related to my problem?

I'm using:

Comment: <mouse touch Lantern>Text: -,-, Normal, Bottom: : Hi! My name's Shelly. on the events.

https://dl.dropboxusercontent.com/u/80991744/TRON/Map003.rvdata2

 

[Shaz]

So even when you're standing right beside it, facing it, and click, it doesn't run? That's very weird. Unfortunately I can't reproduce it, so I've no idea where to start looking for the issue.

 

[Firgof]

So even when you're standing right beside it, facing it, and click, it doesn't run?

That's the gist of it.  But only on some events.  I haven't quite figured out what's causing them to be inaccessible yet.

Unfortunately I can't reproduce it

Well, if the maps I've linked to don't bug out on your end where they bug out on mine then I can't blame you for being unable to reproduce the error.

We should have identical setups if all you've got is the MouseScript running on your end and you're running my maps from Ace's Playtest feature.

Edit: I'm going to see if I can't get you more information by doing some print statements and checking them against expectations.

I can already confirm that the script does get beyond the triggering event step even when the event doesn't run. So, at the very least, @event.start is being called.

I don't know your script or the RGSS3 specification very well but I can tell your script to print things if there's some data that might point you in the right direction?

Edit 2: On events which are failing to trigger in Dim, the normal procedure for your script is to: Face the event, trigger the event if it passes a conditional, and then clear the path.

When the character refuses to move event fails to trigger what occurs is that it faces the event ... and clears its path.  For some reason, the conditional:

if !@started_events.include?(@event.id) && !@map.nil? && !in_airship?is sometimes failing to pass in my game.  I have print statements inside that conditional which trigger when the IF check returns the value(s) you're expecting.  Since they don't trigger, somehow my events aren't returning what you're expecting them to -- but apparently only on my end.

 

[Shaz]

If you want to zip up your project and load it up somewhere, I can take a look at it with the EXACT same setup that you're using.


By the time the event triggers, the mouse script has done its duty and is no longer controlling anything.


Does the same thing happen if you just use the keyboard and not the mouse script at all? If you completely disable the mouse script and use the keyboard?

 

[Firgof]

EDIT:   Sorry for being a pain.  I just discovered it was Autorun causing all these headaches.

I'm used to, when I have an infinitely looping autorun, for no controls to work etc.

This was entirely my expectations playing against your script which apparently breaks from that particular convention.

(it can run during Autorun events)

It's so ingrained in my mind that I didn't even consider it a possibility that I was being infinite loop'd.

Still, weird that you didn't encounter the same weirdness on your end.  And amazing that, despite being infinite loop'd, the script can still run just fine.

Thank you very much for your patience, however.  I'll report any bugs/errors I find as I keep working with the script.

Next time I'll be a bit more rigorous in my checking to see if it's a script error before I submit a bug report.

 

[Shaz]

I did wonder if it might have been a 'lag' issue due to an autorun event, but I couldn't see why that would only affect ONE event out of the lot.


Glad you got it sorted

 

[Firgof]

I was wondering that too just a moment ago.  It's definitely odd that those specific events were the ones to fail.  

Regardless, I'm still reporting the 'have to click twice on an event' bug.  That one's definitely not an autorun-related error.  It can be replicated with this map: https://dl.dropboxusercontent.com/u/80991744/TRON/Map003.rvdata2

Not a deal-breaker for most folks but it might cause frustration in quick-reaction type situations.

 

[Shaz]

Can you test if it happens both when you are away from the event AND when you're standing right next to it and facing it?

 

[Firgof]

When standing next to the event, it works fine.  It's when moving to the event that the event does not trigger (when the player has reached the path's end and has faced the event) unless clicked again.  Or is that by design?

 

[Shaz]

No. I did have that issue happening, but I thought I'd fixed it. I may need to do a little more tweaking. Can you determine if the event.start method is even triggering in that instance?

 

[Firgof]

Update pathfinding is being called but event.start and turn_toward_character aren't.  

Or at least I don't think they are.  Mind that I'm only doing a print statement on lines after any call; I'm not doing tests and printing the result.

So maybe it is being called but the position is invalid, etc.

Edit: Just confirmed by doing a test and print that

if @map.nil? || @map[@x, @y] == 1is returning false on every call of update pathfinding.  Since neither ever evaluates to true, the rest of the events aren't getting called.

Edit 2: If a non-zero offset is specified in the mouse event, it works properly.  If one is not specified (e.g. <mouse touch name> or <mouse touch 0 0 name>), it will never trigger unless activated again.

I guess I'll just use that as my workaround for the time being.

 

[Shaz]

Is the tile your event is on, and the ones surrounding it, passable?

 

[Firgof]

Yep: it's not tile passability at play here.  Each event in the test map is surrounded by one tile of empty, passable, space.  The offset can be to any of the tiles around it and it functions properly.  If one isn't specified, or is specified as 0,0, it never seems to trigger the events.  Now that I've put some thought into it, I think I know what's happening.

The priority of these events are "Same as Character" instead of "Below Character".  If your pathfinder isn't taking the event's @priority_type into account and is trying to reach 'on top' of the event by default, it'd never be able to reach "0,0" because the event itself is blocking it.  ('Same as Character' height events are blocking events unless Through is checked; unlike the default 'Below Characters' and the alternative 'Above Characters')

This leads to two possible 'fail states' from my understanding of the script:

(1) Since the path it wants to take is impossible, it instead moves to a tile adjacent to the destination point.  Since it assumes the event is unreachable, it doesn't bother running the facing and triggering portions.

(2) Since its not expecting a collision until it happens, it cancels the last tile of movement and waits for there to be a path to destination.  Since it canceled the movement but didn't clear the destination, map is not null.  Since it can't reach 0,0 on the event, @x and @y are never 0.  Since neither of those conditions can evaluate to true update_pathfinding can never execute its facing and triggering portions.

In either case: Since I'm now adjacent, when I trigger the event it goes straight to facing and triggering thanks to separate logic being used for adjacent events.

Are either of those plausible explanations?  I'm not a great programmer and I admit I don't fully grasp parts of this script.