Try spawn instead of call

"I am don't use dev branch"

Dev branch is what stable branch will be like, a glance into the future. If you report a bug with stable branch it may already be fixed on dev branch. I suggest you test your bugs on dev branch first before submitting them to feedback tracker, they might be fixed already.

Have you tried it on dev? The physx engine has been updated on dev

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2837471&viewfull=1#post2837471

Does it happen in vanilla game? Could you provide crash report and possibly detailed repro?

no response in 2 months, considering self-resolved

because there are many other, more important things that needs to be done and not enough man power to do them I guess.

or group player == group

Changed Reproducibility from always to sometimes, doesn't happen every time

I have a theory. Since this desync does not happen if ragdoll is forced manually, but only happens when player exit a vehicle on the move, maybe he is still partially considered inside the vehicle while outside of it?

I've tested this on dev, ejecting quadbike, offroad, suv, van... player does not go into ragdoll. Placing player into ragdoll manually synced player position on all clients no problem. There have been some changes though:

"Fixed: Problem with MP synchronization of living characters in ragdoll"

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2839727&viewfull=1#post2839727

Is it possible to test it on dev?

More info:

getPosWorld setPosWorld doesnt do anything
setdir doesnt do anything
in fact direction of the unit is 0 on the client that is not synced

Can confirm this!

Pos on client [1704.5,5650.77,0.00143909]
Pos on dedicated [1704.5,5650.77,0.00143909]
Pos on another client [1655.03,5661.54,0]

Last dev in 2014

can confirm this. getObjectTextures also returns 3 textures but setting 3rd texture does nothing.

Latest DEV (Fri) after 90 seconds of inactivity due to HC crash HC triggers both onPlayerDisconnected and HandleDisconnect events and HC object becomes NULL

So is it working for you now, can it be resolved?

Are you saying you need "deinit" event handler to know when object is deleted so you can delete it? I'm not sure I understand the purpose of such EH.

Thank you for your feedback. Admin ban means you have been banned by server admin.

There is whole other ticket about the inability to change weapons on the move with millions of upvotes. I am asking for repro on inability to change magazine on the move, which should be possible.

no reply in 1 month assuming resolved

No you cannot change weapon on the move, unfortunately, but you can change magazine. Have you got repro?

Not sure what I am kidding you about, that the value 2.9*10^-5 is very small or that there is some mechanism of calculating internal damage redistribution?

As you can see the value is extremely small, probably some kind of internal damage redistribution based on external damage.

Do "other" games allow you to free roam huge maps like Altis as well?

Perks of the engine. They are animated objects that fall through the ground and get deleted for simplicity.

I respect your design decision even if I disagree with it. Any chance a scripted child could be copy pasted with better accuracy, something like hgun_Pistol_Signal_F_Scripted? I dunno, call it "custom tuned" in description :)

Glad you sorted it out!

"No message received for xx seconds" happens when server crashes. But in your case this is unlikely, so it could be that your connection to the server gets interrupted. Could be network card.

Inventory capacity prevented adding large mags, not a bug

"This Rearm eventhandler seems as pointless as the Take and Put eventhandlers are."

Well, LoadOutChanged returns only 1 param, and that is:

"Object - Object that had its equipment changed"

Basically player object. Calling Put and Take pointless when in fact they provide the item put or taken as well as ability to override and information about containers involved in transfer... is a bit of a nonsense, don't you think? Or maybe I misunderstood and you gladly go through the pain of storing and comparing all player's inventory before and after "LoadOutChanged" event just to find out what is that being put or taken? In this case my apology.

this doesnt happen on stratis

Seems that plateFormat in cfgWorlds has extra spaces before and after -

dead unit is still

vehicle unit != unit //true

for maybe 10-20 seconds, then it becomes a body and at this point it becomes

vehicle unit != unit //false

when dead unit becomes a body name becomes Unit: No Name and unit group become <NULL-Group>

There are other problems with this new functionality as both crew and fullCrew show that the place is occupied however you can manually enter it, just not by script.

Since hint does nothing on dedicated server, you must be running it on client, therefore isServer false.

Use getResolution command

That is normal behaviour. Interface size changes viewport size which in turn changes safezone values.

Yeah seems to be the problem with the engine. Found my ticket. Good news it is assigned, bad news, it has been so long means it is not a priority http://feedback.arma3.com/view.php?id=17430

Where are you creating new config, what file?

Alright, you said vanilla and it got me confused, as you are clearly using mod. Have you tried to modify other params, do they work? I assume you did all necessary CfgPatches inclusions and packed it in .pbo before trying?

Thank you for your feedback, but you might find a better response if you post it on official forums.

Side chat only works on client so you dont see the server execution. As it has been pointed, it is not a bug, you should getter a better response on the forums.

Is it still happening? There was a problem with steam authentication earlier on, but it seems to have gone now.

Then you should contact server owner or mod creator as this is unrelated to vanilla game.

Does it happen without the mod?

What about people who expect toggle button behave like toggle button? Do you think they are not going to start complaining "Why my toggle tilt reset when I stop running?"

Well, I would definitely get annoyed about toggle key not actually behaving like toggle.

So you TOGGLE tilt and complain why it is toggled?

There is the reason it is called mini. Also it deals less damage.

Repro is added

Can confirm this. Crouching with launcher takes no time at all to heal.

I'm afraid this is not quite fixed :(

Entering through closed cockpit:

http://www.youtube.com/watch?v=dtwQNqcvTvs

Starting engine and firing outside of cockpit:

http://www.youtube.com/watch?v=FVCrSw8JcKI

Getting out before getting in:

http://www.youtube.com/watch?v=WEP8sVLDLp8

closed at OP's request

Yes, when related to another ticket, the title of hidden tickets gets emailed. I haven't tried the repro, sorry.

"New command setGroupOwner introduced in rev. 129068."

Tomorrow basically, fingers crossed

Local unit disappears from the list of playable units on all clients. Basically it is like it is not even on the server, yet you are connected to one. Imagine what can be done with this in the wrong hands?

I know for sure that BIS have thought about removing createVehicleLocal. Keep talking :)

Resolving as no bug according to dev note.

Can confirm this. The difference is EXACTLY 30 degrees.

Place a AI unit call it bob. Run this

60 spawn {bob setformdir _this; sleep 1; hint str [_this, direction bob]};

result is [60, 30]

180 spawn {bob setformdir _this; sleep 1; hint str [_this, direction bob]};

result is [180, 150]

240 spawn {bob setformdir _this; sleep 1; hint str [_this, direction bob]};

result is [240, 210]

Direction of the unit after setformdir command seems to follow this logic:

if desired bearing is more than 30 degrees from original bearing then resulting turn would be desired bearing - or + 30 depending which way unit is turning.

if desired bearing is less than 30 degrees from original bearing then unit might not turn at all as resulting bearing difference will be less then 30

Very weird behaviour.

Needs repro.

"So a units init is called every time a players joins, on every computer?"

on every computer where unit is created. Obviously if unit already exists locally, the init won't run again on this pc.

The solution to you problem is simple, stop using unit init and use event scripts instead to run your code https://community.bistudio.com/wiki/Event_Scripts

Sounds like you are running some global inventory commands in unit init.

Firstly repro is not vanilla game. If you do want help resolving your issues, make repro on Altis or Stratis.

Secondly, the ticket is quite old, there has been issue with setObjectTexture quite sometime ago, and since has been fixed. It works just fine on dev I just tried.

Resolving this ticket. If you still have problems, make repro on any vanilla map and I will reopen it.

Added diagram. The position should be read where rotation axis comes from the ground. This will also eliminate unit going into falling animation when its bottom is over the edge, because getPos is over the edge

p = getpos player; oneachframe {hintsilent str (p distance getpos player)}

To devs: This little test shows that position of the player may read up to 0.8m from original position by just rotating around. Keeping in mind that sending updated position over network will make everyone else think that unit moved, while it didn't. This would also explain sliding of remote units "on ice" when they just run around turning. Position of the unit should be read from absolute centre of rotation.

If you edit the title and add [RESOLVED] to the text, it will bump ticket and alert moderators

Supposed to be fixed according to http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2817377&viewfull=1#post2817377

no reply in more than a month assuming resolved

What happens when you try to connect?

Closing as resolved more than 2 months ago. Please use forums for any further discussions.

Thanks for suggestion. What would you call it?

Thank you for reporting this.

Can't do that, new people have no idea what key does what. On the other hand there should be UI option so you can specify if you want those actions displayed in action menu or not.

Dev branch had a fix today. The weapon is now prioritised ove inventory as it should. However I am not sure about the rest of functionality.

when weapon is in weaponholder among other things, it is possible to individually pick up other items like headgear, firstaid kit, NVGs from action menu without going into Inventory.

however when weapon is removed, everything becomes just a pile and you need to go through it via inventory.

Intended or still a bug?

"I think every time there is a new "set" command there should be a new "get" command to accompany it."

aye aye captain

should be in tomorrow's dev https://community.bistudio.com/wiki/getObjectViewDistance

CL says it is still ongoing, I guess you had to revamp the whole handler handling, haha

If you read changelog, it says that the fix is ongoing and includes other EHs, this is probably why it didn't make it into this stable. As for this particular fix, it is ok on DEV

Seems fixed in today;s dev

Duplicate of #21718

heli setHitPointDamage ["HitEngine", 1];

and

heli setHit ["engine_hit", 1];

or

heli setHit [getText (configfile >> "CfgVehicles" >> typeOf heli >> "HitPoints" >> "HitEngine" >> "name"), 1];

all work for me. hitengine1,2,... don't work. Latest DEV M-900 in editor, default flying model.

It wasnt closed, strange.

No need to make duplicates, this could be simply unresolved :)

There are setMagazineTurretAmmo and magazineTurretAmmo commands, at least on dev, don't know if they got fixed, they were added half baked.

modelToWorld takes into account vectorUp of the object. While on foot player's vectorUp is [0,0,1], when in vehicle it can be different, tilted forward a bit like in your case.

player setVectorUp [0,0,1];
{_obj = (_x select 0) createvehicle [0,0,0];
_obj setPos ( player modelToWorld [(_x select 1) select 0,(_x select 1) select 1,0] );
_obj setDir ( (getDir player) - (_x select 2) ); } forEach [["Land_HBarrierBig_F",[-5.09961,-26,0],0],["Land_HBarrierBig_F",[-35.5996,3.10059,0],90],["Land_HBarrierBig_F",[4.90039,33,0],0], ["Land_HBarrierBig_F",[41.9004,4.2002,0],90]];

does the trick already, but I suggest you reference the actual vehicle

vehicle player

which should work for both on foot and in vehicle

{_obj = (_x select 0) createvehicle [0,0,0];
_obj setPos ( vehicle player modelToWorld [(_x select 1) select 0,(_x select 1) select 1,0] );
_obj setDir ( (getDir vehicle player) - (_x select 2) ); } forEach [["Land_HBarrierBig_F",[-5.09961,-26,0],0],["Land_HBarrierBig_F",[-35.5996,3.10059,0],90],["Land_HBarrierBig_F",[4.90039,33,0],0], ["Land_HBarrierBig_F",[41.9004,4.2002,0],90]];

EDIT minus vehicle height offset. 1st method is probably better.