itch.io

Somehow I didn’t expect this to have an engine interface, but it turns out that it’s quite reasonable for Window_EquipStatus and only a bit more complex for Window_ShopStatus specifically. The latter fortunately is what BM_ShopCore uses.
(It would actually work already if those windows drew the temporary Actor they use to calculate stat changes, minus Character tags not being taken into account. I’ll fix the latter generally.)

Unlike making the sprites work, this is hopefully not fiendishly complicated, so I’ll give it a go this week.

Good news!

Sorry that it took so long, life kept happening.
This should work in Ver. 1.7.13 after you confirm the plugin settings after updating.

Edit: I haven’t added a setting to exclude rules from on-window characters (only modifiers), but that’s possible. Let me know if you need it.

No, this plugin doesn’t affect draw order.

I normally recommend Galv’s Layer Graphics (MV, MZ) for that purpose, but since it doesn’t use Sprite_Picture, it wouldn’t be affected by Dynamic Pictures.

You may be able to use Dynamic Characters instead. You can use the “!Margins” Plugin Command to display an Event’s entire sprite sheet image. Positioning would be trickier and it would be attached to the Map rather than screen, though.

That’s good to hear.

I found a mention of the controller being supported better starting with Chrome 89, which I think is a bit newer than the Chromium 85 MZ ships with: https://github.com/thayallans/ds5chrome/issues/6

It’s likely technically possible to special-case this on my end if the Chromium version is too low, but in my opinion updating the runtime would be the cleaner solution since that has other compatibility benefits too.

Ah, and another possibility: The DualSense controller is around two years younger than the default runtime that comes with MZ.

Maybe it’s not supported properly by that older version, in which case updating it might fix the issue: https://itch.io/blog/484532/how-to-update-nwjs-in-rpg-maker-mv-and-mz-for-rpg-devs

That would also explain why the controller test site reports everything as centered.

Thanks! The increasing “x” value is actually fine in this case, that’s a side-effect of the plugin interpreting the R-stick as overall outside the deadzone and it being very slightly off-centre.

The main problem is that the fourth axis (which would normally be R-Stick downwards) is being seen as -1, i.e. all the way up.

Maybe the controller has a different axis layout due to the gravity sensor.
I you could add console.log(axes, gamepad.mapping, deadzone); at the second insertion, that should give me enough information to at least look this up. (You can remove the other ones.)

It would also be helpful to know which numbers in the axes array change when you move the R-stick.
If the axes are indeed different, then that along with the mapping or id will be enough to special-case it.

There’s another place that could be helpful:

Where it says

dx += x;
dy += y;

add console.log(x, y, gamepad.id); so that it’s:

console.log(x, y, gamepad.id);
dx += x;
dy += y;

This should show any devices that the plugin sees as controllers.
(Edit: I should be able to exclude the one that causes problems, that way.)

There’s one other place where the plugin can move the cursor, that this doesn’t cover, but that is only reachable when using the “Point at” plugin command.

I forgot that I used locals, which are a bit more difficult to debug.

There’s a line in the plugin that reads

x += dx, y += dy;

please insert console.log(x, dx, y, dy); directly above that so that it reads:

console.log(x, dx, y, dy);
x += dx, y += dy;

Press F12 and tell me what’s shown in the console there, if anything, when the cursor moves:

Right, and it’s the left stick that’s non-zero, which schold have no effect.

I’ll try to replicate this here with the newest version of the MZ core scripts.
If I can’t figure it out that way, I’ll reply with a few JS commands that should help with debugging this.

How fast does the cursor move upwards?

Could you check what https://controllertest.io/ shows (for all controllers it reports as connected)?

There were problems before where certain other hardware appeared as controllers with different axes, throwing the plugin off.

This is explained in the following paragraphs. It depends on the operating system and whether you’re updating the Maker’s versions or a published game, so I can’t give you a direct answer here.

In general though, for published games you only need the “Normal” version. The “SDK” version goes into the -test folder, for other runtime folders use the “Normal” version.

Does this have options on which plugins it affects?

If used on mine (TS_, TSC_, TSk_ so far), it would most likely break the license terms since retaining them and noting edits is required. I can’t easily test this right now due to mostly using Linux, though.

Thanks, I’ll try to have a look later this week!

This is now fixed in Ver. 1.1.1.

I missed the Face Size customisation that MZ supports 🫠
I’ve fixed that locally, so it’ll be in patch level 1 some time later today.

You’re welcome, it only took a few minutes to find with your description.

If you’d like to help me out in return, please consider mentioning me to other RPG devs you know. My plugins aren’t flashy, so the grapevine seems to be more effective for actually getting eyes on what I make 🤔

This bug is now fixed in Ver. 1.1.5: Boundary indexing fix.

Regarding ”[Violation] ‘requestAnimationFrame’ handler took ###ms”, that’s a performance warning with unspecific cause. It means something took too much time and caused a lag frame.

You can figure this one out using the profiler, but usually it’s just something like resource loading not running in parallel.

This is now available as Window_Base.drawText Ignore CanvasTextAlign Numbers.

A call stack would help, but a a 36 appearing there sounds like someone is calling drawText on Window_Base as if it was the method on Bitmap. The former doesn’t have a lineHeight parameter preceding align.

I’m pretty certain that this line here in Window_EquipSlot.prototype.drawItem is the culprit:

The bug is present in both MV and MZ, but fixed in the YEP_EquipCore.

You can just delete the , this.lineHeight() part there to fix this, but I’ll make plugin to auto-check that argument tomorrow, too.

That’s a great bug report, yes, especially that it gives me a good way to reproduce the issue.

I roughly know what causes this. I’ll play around with the rounding a bit to see if I can fix this pixel-perfectly (or at least clamp it to the correct area of the bitmap). Might take a few days though, it depends on how busy I am next week.

Are you using the latest version 1.1.4?

It’s Bitmap.drawText CanvasTextAlign Default Fix / TSk_Bitmap_drawText_CanvasTextAlign_Default_Fix.js, to be specific.

Note that I defaulted it to ‘start’ instead of ‘left’ since I think that’s what the web API does internally when that error occurs.

Done. I’ll update the page in a moment, but the file is there.

(Untested, but it’s a really simple issue and I’m quite confident.)

No worries 🙂

Admittedly, this only happens to work because I wanted to support distinct left- and right-click behaviour on the same Event (the hover tags are combined between those entry points, btw), but this approach that makes use of the existing engine is something I aim for in general.

That’s (part of) why so many of my plugins are rule-based instead of relying on Note Tags now.

Use “Exit Event Processing” as first Command and then “!OnTouch:” right after.
(“!OnTouch:” acts as entry point, so Event processing will start right at that line.)

The Event may still turn to face the Player if it’s not Direction Fix.
If the Event should turn, you can do that manually with “Set Movement Route…” (“Direction Fix OFF”, “Turn Toward Player”) and then reset with “Revert OnTouch Turn” and “Set Movement Route…” (“Direction Fix ON”).

Glad to hear that!

If the lag gets too serious, a “fix” may be to use another plugin to draw the cursor onto the canvas, but that only makes both lag synchronously which I don’t love. (It can be quite noticeable at lower frame rates.)

If there was a native-cursor changer with tags feature, I could probably integrate with that. Maybe I’ll make one eventually, but it’s likely quite a messy project and could cause a lag frame when the cursor is adjusted.

If I read the source code right, this doesn’t handle the boolean parameters correctly yet. RPG Maker recursively encodes all except string-like (except @type note, that one is encoded) parameters as JSON, unfortunately.

Ideally, you should also handle the empty string, since you can easily delete the parameter values with Del/Entf.

And thank you for your patronage, of course! Very appreciated.

Ver. 1.1.4 is now online and includes direct getImageData parameter validation.
I hope that I also fixed what was causing the invalid parameters in the first place (at least when the window isn’t shrunken), but that’s tricky to debug and with this check it won’t crash.

Just a heads-up that I’ll upload another small patch most likely tomorrow since I didn’t quite get the bug I thought I fixed last time.

There won’t be any changes to the parameters or behaviour, but if you get a type error while hovering over a sprite that overlaps the edge of the window, that’s likely that. (It’s annoyingly hard to debug because I can’t reliably provoke it.)

You can likely replace the icon using this old program: https://www.angusj.com/resourcehacker/
I remember using that to get my hands on executables’ icons as a child 😄

That warning is most likely just because RPG Maker picks text colours from the window skin image. It’s not optimal, but as far as I know doesn’t happen anywhere close to frequently enough that it would cause a noticeable slow-down.

Fair enough. As long as they don’t change anything noticeable by default, it should be fine.

I’ll wait until the dead code is cleaned up then to see which APIs I can actually use.

I think I can work with this, but I’m not sure why you tried to replicate the Game_Picture/Sprite_Picture API, i.e. the new

get _pictureName() { ... }
set _pictureName(value) {}
picture() {}

that you added to Sprite_UIPicture. These aren’t useful as extension points since they aren’t used internally by your plugin at all.

You also exposed the classes on window directly, which increases the risk of collisions with other plugins. (Letting third-party plugin devs replace classes entirely in not very helpful, as it makes for very brittle integrations that risk crashes as plugins are updated.)

I’ll probably postpone this for the time being, since you also started to mix in other features. I don’t think that’s the sort of clean single-purpose plugin I was looking for.

Thanks, that sounds perfect! I’ll have a look soon.

I just submitted a refund request to Itch. In my experience these should go through relatively quickly, but do let me know if it takes longer than a week.

Close call for “within this year still”, but I made it I think ;)

Version 1.1.2 has this now (a bit more powerfully than you might expect). I’m a bit occupied with family/vacation, but I’ll likely be able to update the page text in a few hours.
Note that there’s a slight time lag between native cursor movement and how these hint sprites move, which I don’t think I can avoid.

Thanks a bunch for the write-up!

Have you tried using the normal/non-SDK version on deployed games? As far as I can tell, that’s usually the one RPG Maker deploys games with. Maybe the folder structure changed too much between versions of NW.js to update it directly in the install directory though.

I mentioned this in the Discord but it seems you forgot:

I’d like to add specific support for this plugin to Dynamic Pictures. To do that, it would be helpful if Sprite_UIPicture and ideally also Sprite_UICommand were exported in this plugin’s API.

In my test, it seemed to play the skill animation and then a miss/evade motion on the target.
I just tried changing Game_Action.prototype.executeDamage instead, but got the same result.

At least currently, it doesn’t look like something I’d be likely to figure out within an hour, so a ‘true miss’ implementation that doesn’t show the skill animation isn’t something I’ll attempt for now.

Edit: Typo.

The ‘fake’ implementation was easier.

I also made one that reports those zero-damage hits as evaded instead, since it was a one-word difference.

Sounds doable, and like a good small request!

To clarify, which one would you prefer:

• Damaging actions that do 0 damage miss instead (true miss) or
• the target and text/visuals will act like there was a miss (fake miss)?

I haven’t looked at the code yet, so this is just in case either isn’t too complicated for a “sketch plugin”. It could make a difference in terms of side effects (like whether status effects are inflicted).