Page MenuHomeFeedback Tracker

A weird GetIn event handlers behaviour
New, NormalPublic

Description

Situation: there is the GetIn EH attached to one of the land vehicles. Inside the EH code, I want to check the unit side (for example, to change vehicle's owner):
params ["_unit", "_role", "_vehicle", "_turret"];

if (side _unit == WEST) then {...}

Sometimes, when vehicle to which the EH was attached, is destroyed with bomb/missile, the game throws a log error:

Error side: Тип Число, ожидался Объект,Группа,Location (Type is Number, expecting Object, Group, Location)

I've checked the _vehicle param, and it is, for example, 3.03861

The vehicle itself has tow additional objects attached to it (to make it targetable, objects are based on I_TargetSoldier class).
Once vehicles destroyed, the script removes crew from those attached objects, removes objects themselves, and attaches the vehicle wreck to an invisible object (to keep the correct wreck height).
Seems like for vehicles without attached objects all works as expected.

Details

Severity
None
Resolution
Open
Reproducibility
Random
Operating System
Windows 7 x64
Category
Scripting
Steps To Reproduce

I wasn't able to reproduce it in editor.

Event Timeline

MaxP created this task.Apr 12 2023, 6:44 PM
This comment was removed by Geez.
Geez added a subscriber: Geez.Apr 14 2023, 10:58 AM

Are you saying _unit becomes a number? Cannot happen by design, you can prove the engine wrong by adding a repro to this ticket.

This comment was removed by BIS_fnc_KK.
MaxP added a comment.Apr 15 2023, 5:33 PM

Cannot happen by design, you can prove the engine wrong by adding a repro to this ticket.

Unfortunately, I have no enough skills to reproduce it in editor, it can only be reproduced in my mission, and I understand that it would be very hard for devs to reproduce it without knowing such info.

you can prove the engine wrong

I think the log entry is enough to prove that something goes wrong :)

Leopard20 added a subscriber: Leopard20.EditedApr 15 2023, 6:56 PM

Well you can post your entire mission with all the scripts so the devs can investigate the scripts directly.

I think the log entry is enough to prove that something goes wrong :)

Not unless you do something wrong. (which is why posting your scripts will help)

MaxP added a comment.EditedApr 16 2023, 12:03 AM

Not unless you do something wrong. (which is why posting your scripts will help)

Depends on what do you mean under "doing wrong". If it means just creating GetIn EH according to official wiki, and getting weird results, then I don't think I'm doing it wrong :)

Well you can post your entire mission with all the scripts so the devs can investigate the scripts directly.

If someone really interested, I can communicate with him directly to help to investigate that issue - but it is large in size.
https://steamcommunity.com/sharedfiles/filedetails/?id=1972510873
I can prepare the save and scripting commands to recreate the situation.

Depends on what do you mean under "doing wrong"

for example we had a very similar report when EH supposedly fired with params of another EH. As it happened the mission maker called function from EH which through some script error was also called from another EH. So unless you have a repro, not much we can do.

MaxP added a comment.EditedApr 16 2023, 3:38 PM

As it happened the mission maker called function from EH which through some script error was also called from another EH

In my case, the EH added in CBA FrameHandler cycle. I have already encountered a couple of serious bugs in CBA functions, and more than once I regretted using them in complex scripts.
The first one: https://github.com/CBATeam/CBA_A3/issues/1570#issuecomment-1465218758
The second one happened in the same PFH loop, just a bit above:

{
	private _idx = 0; // A "flag" to detect the first and the second vehicle
	{
		private _cls = _x;
		if (_cls isKindOf "LandVehicle") then {
			if (_idx == 0) then {
				_veh = createVehicle [_cls, [3274.82,12969.3,0.110337], [],0, "CAN_COLLIDE"];
				_veh setdir 178;
				// Here _idx is still 0
				[_veh,grpNull] call OT_fnc_veh_replace; // A large procedure to preapre the vehicle
				// And here **_idx becomes -1**!
				_idx = _idx + 1;
			} else {
				_veh = createVehicle [_cls, [3260.0,12969.0,0.110337], [],0, "CAN_COLLIDE"];
				_veh setdir 178;
				[_veh,grpNull] call OT_fnc_veh_replace;
			};
		} else {
			// the remaining code (it has no _idx reference at all)	
		};
	};
} foreach [two vehicle classes to spawn amongst other stuff];

So I think I need to rework the loop, using only standard methods.

So unless you have a repro, not much we can do.

I have a repro, but it needs the mission to be loaded with all requirements :)
Anyway, if it turns out to be the CBA's issue, then, most likely, it has no sense.

Added:
I've reworked the script, the issue with -1 I mentioned above is gone, but the EH still see the number instead of unit. So CBA is not the cause in this case.

I have a feeling you're not privateing your vars, causing them to be changed by an inner function.

MaxP added a comment.EditedApr 17 2023, 8:41 PM

If you mean the -1 issue - as you can see, all variables "privated" correctly, and there are no such variable names in upper scopes.
Also I mentioned that variables changes after the function call.
Current CBA realease has some problems with variables scopes - see the link above.

As CBA devs pointed out to you, it's not a CBA issue.

MaxP added a comment.EditedApr 18 2023, 7:12 PM

As I described in the ticked, it happens ONLY in CBA functions.
If it is not a CBA function bug for any reason, then it is the bug of CBA + something, so it may be important only for CBA developers, not for debugging from my side.