itch.io

It working exactly once is strange. Are you sure it doesn’t depend on the direction the cursor moves in? Does anything change depending on which order the two plugins are loaded in?

If there was an error message in the debug console, that could give me a hint, too. Otherwise, it may be easier to ask Olivia about this, since her plugin is paid and I don’t have access to it.

I’m available for questions if needed, and if she’d like me to make a specific change for better compatibility, then I’ll gladly do that (within reason).
Beyond that, it’s not always feasible for me to provide compatibility support regarding specific third-party plugins, so while I generally give it a try, please understand that it’s not guaranteed unless mentioned directly here on Itch.

Thanks, that was fairly straightforward.
I ended up making it optional (OFF by default) since the integration is only needed when both plugins are used on the same Picture.

I made sure to first check in CGMZ.Versions and added a warning (to nudge me about it) if there’s a version mismatch.

Easy 5★. I’m aware this is alpha stage, but it’s already very solid.

I noticed that mouse enter will only fire if the cursor moved, but mouse exit works fine if the Picture is moved away.
There are some good reasons it’s implemented this way by default, but an equivalent option to “Event Touch” would be cool to have (for avoidance QTEs).

Something else I’m missing is the option to attach a sound effect directly. I know that’s possible through JS, but is less convenient without the picker. I’d understand if you think that’d make it too cluttered, though.

A technical suggestion: I think it would make sense to call ImageManager.loadPicture for the alternative images as part of the Attach Command and Sprite_Picture.prototype.initialize, to make sure the bitmap change doesn’t flicker or lag.

Lastly, a question: Would you mind if I treat cgmz_altImages and the cgmz_…Pressed properties as public API?
One of my plugins causes Game_Pictures’ names to vary, so I’m thinking I may absorb the alt images configuration and inject the values contextually based on hovered/pressed state on my side.
I can always check the object shape a bit more thoroughly if you think you may change this is the future, though.

Oh, I had gotten this in a bundle already 😅
Ah well, consider it a small tip 🙂

If it’s not too much hassle: I’m doing this myself right now, but a FLAC version with the MP3s’ meta data would have been convenient. If I convert with --best from the WAVs, most of them fit into a bit less than half the original size.

Maybe it would be possible to make the (clearly labelled) buggy version available officially as bonus to an eventual fixed version? 😄

I have the Steam version too, so no pressure, but it was a nice surprise to stumble across the soundtrack when I checked your page due to the Itch feature of A MANSION on the HILL today.

It would be helpful if these came with comments explaining the issue they work around 😅

I believe 1-3 are either plugin-specific or target older versions of the core scripts, since I can’t find their "key" in my project folder.
4 has roughly the same effect as my “Bitmap.drawText CanvasTextAlign Default Fix” sketch plugin.
5 I believe is a workaround for something that can occur on mobile due to texture size limits. It also just masks an error with potentially unintended behaviour instead of really solving it.

I think the additional ones are out of scope for me.

There’s currently still a small problem with how the 0/None-Actor condition (first party member) is checked. I’d used the object identity instead of the ID there and that check of course fails for equipment previews.

I’m a bit too swamped right now to do another release just for that, but let me know if you run into it and I’ll prioritise it. (Goes for anyone else too, of course!)

I’ve fixed it locally already, so at the latest it will be part of the next feature release. At which point I’ll hopefully get around to updating the store page here, too.

Done: Ver. 1.8.14: Equipment Previews and paintOpacity support

I underestimated the complexity somewhat 🫠
On the plus side, I fixed more issues along the way.

There may be small differences (only with equipment slot plugins, I think) in how BM MV Shop applies equipment to calculate the stat differences vs. how Dynamic Characters constructs the preview (optimal slot). Players should be unlikely for to notice that, though.

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: /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.