If ShowPlayerCharacter=false mouse animation doesn't work

[san.daniele]

i don't know if this fits here or if there's a good reason for AGS to behave like this.  The Editor developement forum might be a better place, I decided to post here so it might help others in the future (as it drove me crazy for hours before finding the solution).

if ShowPlayerCharacter is set to 'false' in the room properties, the mouse cursor animation doesn't work!
(correct me if I'm wrong about this, but the problem is easily recreateable)

I'm surprised I couldn't find several topics about this, as I'm pretty sure many stumble over this issue (mostly on Start Screens / Settings / etc). Placing the character outside the visible area of the room is an easy workaround, but it seems a workaround for a problem that shouldn't exist in the 1st place.

p.s. is ShowPlayerCharacter - or any other room properties â€" missing in the manual?

[Khris]

I can not replicate this, mouse animations work fine when ShowPlayerCharacter is set to false.

However, when testing this, I assigned a view to the walkto cursor at first, and when I turned off the option, the initial mouse mode was now eModeLookat; looks like AGS automatically disables eModeWalkto, which seems like a reasonable thing to do.
I guess what you saw wasn't a no longer animating walkto cursor but the not yet animating lookat cursor, which uses the same graphic?

[san.daniele]

looks like AGS automatically disables eModeWalkto, which seems like a reasonable thing to do.
I guess what you saw wasn't a no longer animating walkto cursor but the not yet animating lookat cursor, which uses the same graphic?

aaaaah!! (huge bright light and monumental music all around me)
you're absolutely spot on! I wouldn't have thought about a disabled mousemode in a million years.

[monkey0506]

It's actually interesting behavior that AGS disables cursor mode 0 (typically named eModeWalkto, but regardless of the actual name) if the player isn't shown in the room, and yet if the player is shown, AGS won't allow you to disable it (IIRC).

I really think the engine should break away from any hard-coded behavior regarding cursor modes like this.

[Khris]

Another thing eModeWalkto (or mode 0) does is not trigger any_click_on_x.
As long as this is well documented, I do think it makes sense, especially given how easy it is to code a custom cursor system that uses only, say, eModeInteract.
An adventure game engine needs at least a dedicated useinv cursor, right?

Granted, it can be irritating to learn about those quirks while trying to do something for hours, but in the end it's a feature, not a bug.

[monkey0506]

While I do agree that in the terms of a strictly classical adventure game engine, this could be marked as a feature. However, modern adventure games don't always abide by these rules.

I don't think that any cursor interactions should be hard-coded into the engine (no, not even for "useinv"). That's why we distribute templates with the editor. They can provide the "default" behavior for these modes "built-in".

The editor should be (IMO) modified so that the properties pane reflects only and exactly the cursor modes that currently exist. Each cursor mode would then independently have the option of linking an interaction method. "Any click" should register any click (even handled ones, but the handler should take precedence and have the ability to call ClaimEvent). There should also be "Unhandled click" events for each interaction (e.g., in each Character's Properties pane, collectively handling all unhandled cursor modes). Each cursor mode should have an independent toggle to "Use active inventory as graphic".

This would give the developer total control over the cursor modes, which would be a vast improvement (again, IMO) over the current implementation.

All this is getting extremely off-topic. Sorry for the derailment.