Failed to identify animation source

[CuriousMike56]

In version 2022.12+ command-triggered add_animation lines are no longer parsed correctly, showing Failed to identify animation source in the log:
https://forum.rigsofrods.org/resources/centerline-40t-rigid-neck-lowbed.720/

;Animations
129,131,133,0.0,0.0,0.0,180,0,-90,  Centerline40T-flag.mesh
add_animation  0.1, -18.0,0.0, source: event, mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_15
add_animation -0.1, -18.0,0.0, source: event,  mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_16
135,137,139,0.0,0.0,0.0,180,0,-90,  Centerline40T-flag.mesh
add_animation  0.1, -18.0,0.0, source: event, mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_15
add_animation -0.1, -18.0,0.0, source: event,  mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_16
130,132,134,0.0,0.0,0.0,180,0,-90,  Centerline40T-flag2.mesh
add_animation  0.1, -18.0,0.0, source: event, mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_15
add_animation -0.1, -18.0,0.0, source: event,  mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_16
136,138,140,0.0,0.0,0.0,180,0,-90,  Centerline40T-flag2.mesh
add_animation  0.1, -18.0,0.0, source: event, mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_15
add_animation -0.1, -18.0,0.0, source: event,  mode: x-offset,   noflip,  autoanimate,  event: COMMANDS_16

The flags on this trailer are supposed to move to their correct locations when pressing CTRL+F3/F4 (2022.04):

RoR_2023-03-31_14-37-32.mp4

This issue primarily affects Negativeice's mods. Another example:
https://forum.rigsofrods.org/resources/komatsu-d39ex.416/
Strangely enough, the joystick animations on the D39EX still function despite throwing the same error.

[CuriousMike56]

It seems any "event" source is affected by this issue:
https://forum.rigsofrods.org/resources/tatum-class-1-buggy.325/

1, 19, 46, 0.5, 0, 0, 0, 0, 0,		class1buggy-pulleys.mesh
add_animation 	5,	0,	0, 		source: tacho, 	mode: z-rotation
add_animation 	0.05, 0, 0, 		source:event, 	mode:y-offset, event:TRUCK_STARTER, eventlock

[ohlidalp]

I just took a quick look, it got broken here: #2949 - specifically this commit e583df2.

There are actually 2 bugs there:

• The "Failed to identify animation source" message appears for every event-triggered animation and doesn't indicate anything. This is simply because the SOURCE_EVENT bitmask is now set later than the check is done.
• The problem described above - I need to investigate further.

[CuriousMike56]

Other trailers with the same problem as the Centerline:
https://forum.rigsofrods.org/resources/trout-river-live-bottom.104/
https://forum.rigsofrods.org/resources/55-ton-fontaine-eagerbeaver-rgn.621/

[CuriousMike56]

Turns out the animations work as intended if a truck is attached and you activate the commands from the truck:

8mb.video-00U-92fMXJoO.mp4

[ohlidalp]

Turns out the animations work as intended if a truck is attached and you activate the commands from the truck:

@CuriousMike56 I don't really understand how this is working; either way, is there anything I need to fix or can this be closed?

[CuriousMike56]

@ohlidalp The problem is that the animations only work when a truck is attached, they should function regardless of connection. And there's also the misleading "Failed to identify animation source" error that spams the console.

[ohlidalp]

@CuriousMike56

The problem is that the animations only work when a truck is attached, they should function regardless of connection.

Ah, thanks for clarifying, I wasn't sure if that quirk is undesirable or mods use it. Very puzzling, tho.

And there's also the misleading "Failed to identify animation source" error that spams the console.

I was sure I fixed that one bit long ago... I guess not. Let me take a look. UPDATE: Sure enough, I can't reproduce it.

[ohlidalp]

Got it. The anims don't activate because they're event-triggered, and input events are only evaluated for trucks (with engine), not trailers.

The check is here:

rigs-of-rods/source/main/main.cpp

Lines 1144 to 1147 in 8d3914b

	if (App::GetGameContext()->GetPlayerActor()->ar_driveable == TRUCK)
	{
	App::GetGameContext()->UpdateTruckInputEvents(dt);
	}

- trailers have type NOT_DRIVEABLE, not TRUCK.

The whole enumeration is

rigs-of-rods/source/main/physics/SimData.h

Lines 99 to 109 in 8d3914b

	enum ActorType //!< Aka 'Driveable'
	{
	// DO NOT MODIFY NUMBERS - serialized into cache file, see RoR::CacheEntry
	NOT_DRIVEABLE = 0, //!< not drivable at all
	TRUCK = 1, //!< its a truck (or other land vehicle)
	AIRPLANE = 2, //!< its an airplane
	BOAT = 3, //!< its a boat
	MACHINE = 4, //!< its a machine
	AI = 5, //!< machine controlled by an Artificial Intelligence
	};

- there is no 'TRAILER' category.

The identification is done when generating modcache:

rigs-of-rods/source/main/resources/CacheSystem.cpp

Lines 903 to 906 in 8d3914b

	if (def->root_module->engine.size() > 0)
	{
	vehicle_type = TRUCK;
	}

I could add a TRAILER actor type, the question is how should it be recognized. I could check for fileinfo category 117 (Trailers) and make sure it has at least 2 wheels (because i.e. Neg's RockPack also uses 117, probably by accident).