Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

EHs extended instead
Rev 151794

I was linking my mods manually by loading the -addonsDir in steam for testing and I think that when the game would update a mod, it would wipe the old one from the addons directory, if it was in there.

Hello Geez,

The game already has destroyable doors, they are glass doors. So I thought maybe allowing wooden doors to break wouldn't be such a big task.

In T179349#2573141, @Geez wrote:

Hello everyone.
Sounds like what you want to be using is HumanInputController.OverrideRaise. Here is some example code that works:

modded class PlayerBase
{
	override void CommandHandler(float pDt, int pCurrentCommandID, bool pCurrentCommandFinished)
	{
		HumanInputController hic = GetInputController();

		float movementSpeed;
		vector movementDirection;
		hic.GetMovement(movementSpeed, movementDirection);

		// Only raise if player is moving
		if (movementSpeed > 0)
		{
			hic.OverrideRaise(HumanInputControllerOverrideType.ONE_FRAME, true);
		}

		super.CommandHandler(pDt, pCurrentCommandID, pCurrentCommandFinished);
	}
}

I'm looking forward to the next profiling branch!

Looks like it should work. I found that node type in infected animgraph. It looks like problem is I am trying use IK anim as additive (want have modified fingers). I apologize, ticket can be closed.

Another thing that might help is adjusting spawning to not use your Rambo (saved) kit. It's kinda ridiculous that you can just keep sending in wave after wave of geared guys (with tons of rifle grenades and RPG's), while if the defenders are being smart they will save supply by using default kits and recovering gear from the battle.
I am also uploading a pic of a "radio group" somebody made to increase their spawns. While the positioning is terrible if I'm honest, the idea is solid.

If you by any chance get a Steam ID of a hacker that is not being banned, please contact BattlEye directly at https://www.battleye.com/contact/ and they will check the suspicious player for any malicious software use.

Next profiling and dev branch

This bug happened because the unit needs to be notified that their inventory contents have changed.
With the commands that get the unit as argument its easy, the unit is right there.
But the commands that get a container, first need to find which unit it belongs to, and there might not be any unit at all.

In T180137#2597902, @dedmen wrote:

You can already see in your chat display bottom left, who is transmitting right?

@dedmen thanks a lot for looking into it and sorry for the belated response!

Hello blackburn.
This is intended.
"Main reason why location hint was added back then was that players were lost in conflict. Since combat ops has different "rules" and player knows where they will spawn (in deploy menu - also in map) we don't need this location hint also because navigation and exploration should be part of the immersion of the whole combat ops experience"

Thanks for the hint that we have the visor up model, that makes testing easy

class CfgWeapons
{
	class ItemCore;
	class H_HelmetB : ItemCore
	{
		class ItemInfo;		
	};
	class H_PilotHelmetHeli_B : H_HelmetB
	{
		class ItemInfo: ItemInfo
		{
			modelHMDOff = "A3\Characters_F\Common\headgear_helmet_heli_visor_up";
			uniformModel = "A3\Characters_F\Common\headgear_helmet_heli";
		};
	};
};

The method worked, thanks.

Config name for this is modelHMDOff
Behaves same and switches at same points as the HMD item.

Hello patriaminas.
Can you please provide us with coordinates of where this occurs?
Regards,
Geez

Hello blackburn.
This is intended, they never were interactive for the mouse which confused players before, there are buttons on the line of the controls that replace the keyboard controls.
Regards,
Geez

Huh. Weird that we didn't find that before.
Thank you, the crashdump was enough to see what was going on. Fixed next profiling/dev branch.

next prof

I hope it will be fixed with next profiling branch update, v5.

difficulty setting seems very unlikely to happen. a scripting command may be more possible

https://steamcommunity.com/sharedfiles/filedetails/?id=3150497912

Also, I know about the cases when a model has been attached to the DayZ native zombie skeleton with the same broken behavior. Unfortunately, I can't provide the p3d because I don't have it. The screenshot is all I have

@Geez Yeah, we use different skeleton with its own bones, animations, nodes and etc. I can share the full pack with you if it would help. But the problem still exists only with p3d and model.cfg

In addition, I want to say that I am sure that the amount of attached weights is not higher than 4 different bones/vertex groups on every single vertex. Every single vertex is also attached and normalized. We've made some investigation in this direction and tried to limit the number of simultaneous weights per vertex. It didn't really help until we reached 1 weight per vertex group