i think it's to do with graphic card,i have intel weak graphic card and AMD radeon graphics. i just bought laptop brand new.

all games work fine.

yeah on all game modes, main menu also

if you run these https://github.com/Fankserver/ArmA3BugSamples/tree/master/18451 in editor preview now many FPS does it say? without using the action just the FPS in the chatlog

i run on a 5760x1080 resolution with 2x NVIDIA GTX760 in SLI with about 70FPS, so please answer my question to reproduce it.

"no matter what graphics is it goes to 20 max." where?
Mainmenu, editor or multiplayer?

Yep sadly, even if lower the sampling to 50% i get like 25 fps so does lowering the resolution.

i have like switchable graphic cards, i have tried switching it to high performance nothing changes.

so... your only complaint is that the parachute open on will? in A2, granted, they opened depending on wich parachute you were using, but you have to talk aboug what else if you plan to make a ticket out of it.

I think he is complaining about the entire system - IE they way you leave the aircraft and how the parachute handles

What he is asking for is an Ejection seat ( or at least an animation that resembles an ejection seat)

and for the parachute to open automatically

but I think it should be a feature request not a bug

as it stands , that's the way the system was designed , what you are asking is to change the design not because its not working but because it doesn't resemble your take (and myn) of how an ejection from an aircraft should be handled

that's a feature request

even on OFP the player was "ejected"

but i think you want something more like the F-18 addon for arma 2, in wich you are ejected after a few secodns with the seat and then in the fall you drop it as you fall

I see it as more or so, Half/Half. As it is a feature request, but at the same time, it's half in the game. The jets have seats. However, when you eject, you fly up and out, as if you were shot out of a cannon. What needs to be done, is much like the video shows. The cockpit is animated, so with an eject, it shouldn't be hard to have the cockpit break away, you are jetted out WITH the seat, and your chute opens automatically at a set time after your out of the cockpit.

somewhat related to my issue here: 18506 discussing how ejection, whether done properly or not, is practically useless.

Hello,

thank you for your report and files. It seems that your problem is that DirectX crashes. This may be from various reasons, such as outdated DirectX, outdated drivers, overclocked CPU or GPU [by manufacturer or user] and many more.

Sadly, there is nothing that can be done from our site. I linked this problem to bug number #0000579, where you can read useful tips in comments.

Sorry for the inconvenience, have a nice day.

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Hello,

it is fixed locally and should project to Steam Dev in couple of days.

Thank you.

I think I misunderstood you after reading it again now, sorry. You mean purely the actual HUD display on your screen and visible range of the 'dots'. I also thought you meant the range AI can spot/detect other AI (cos thats determined by viewdistance).

You are right thus :)

Well I have a view distance of 5,5km all the time.
And maybe you are right. But then how does the radar in jets work?

Once you set your viewdistance above 2km the AA vehicles lock/spot/engagement range does not increase anymore, while those of other units do increase further.

If you have distance at 2km then you won't spot a thing in the air + lock range is also limited by view distance. Radar in amra does not work like a real radar (360 degrees scan) it depends totally if a unit visually spots the aircraft (thus view distance), aircrafts don't automatically show up on radar within a range, but only when it has been actively spotted.

Correct me if I am wrong, but it seems to work like this.

Increase your view distance. Voila, more range.

The view distance has nothing to do with the radar distance.

And then parachutes explode when they hit the ground.

Upvote. I have test this with Cargo Parachute and C-17 mod.

I have the same issue in my mission. The eventHandler doesn't appear to fire when one player (as a medic or not) attempts to heal another player when using the FAK, but it does fire when healing self.

Hello,

thank you for submitting the ticket. Could you please upload a repro mission for two players? It would help us a lot.

Thank you very much!

The code with allunits is just to test if it works for you, as it does for me. For some reason the event handler has to be assigned on the healer pc to the injured for it to fire when you heal the injured. It will fire on your pc obviouly. If you expect it to fire for injured on his pc when someone is healing him, this doesnt work.

I can confirm this. The eventhandler is not being fired when a player heals another player in a multiplayer mission, only when the player heals himself.

Also the third argument healercanheal is always false. When a medic heals himself it should be true.

Try assigning EH to the injured on the healer PC. Run this code before you heal another player:

{
_x addEventHandler ["HandleHeal", {

		player sideChat str [name (_this select 0), _this];

}];
} forEach allUnits;

It should fire when you start healing him.

Hello killZone Kid.

First thank you.

I am unsure what you mean exactly or how it differs from what we do, so I will explain how we call the EH.

In the initPlayerLocal.sqf we do :-
call compileFinal preprocessFileLineNumbers "core\FAR_revive\FAR_revive_init.sqf";

In the FAR_revive_init.sqf we do :-
call compile preprocessFile "core\FAR_revive\FAR_revive_funcs.sqf";
player removeAllEventHandlers "HandleHeal";
player addEventHandler ["HandleHeal", dr_handle_healing];

In the FAR_revive_funcs.sqf, we have the function dr_handle_healing ={}; as posted in the first additional information post.

I don't see how what we do differs from running a foreach allunits.

But we will try your example :)
I just thought I should explain our process first.

Хорошо хоть вообще что-то делают

This is now fixed.

Не прошло и полутора лет! Можно закрывать!

Already fixed.

<Key ID="str_a3_cfgweapons_arifle_trg200">
   <Original>TRG-20 5.56 mm</Original>
   <English>TRG-20 5.56 mm</English>
   <Czech>TRG-20 5,56 mm</Czech>
   <French>TRG-20 5,56 mm</French>
   <German>TRG-20 5,56 mm</German>
   <Italian>TRG-20 5,56 mm</Italian>
   <Polish>TRG-20 5,56 mm</Polish>
   <Portuguese>TRG-20 5.56 mm</Portuguese>
   <Russian>TRG-20 5,56 мм</Russian>
   <Spanish>TRG-20 5,56 mm</Spanish>
 </Key>
 <Key ID="str_a3_cfgweapons_arifle_trg210">
   <Original>TRG-21 5.56 mm</Original>
   <English>TRG-21 5.56 mm</English>
   <Czech>TRG-21 5,56 mm</Czech>
   <French>TRG-21 5,56 mm</French>
   <German>TRG-21 5,56 mm</German>
   <Italian>TRG-21 5,56 mm</Italian>
   <Polish>TRG-21 5,56 mm</Polish>
   <Portuguese>TRG-21 5.56</Portuguese>
   <Russian>TRG-21 5,56 мм</Russian>
   <Spanish>TRG-21 5,56 mm</Spanish>
 </Key>
 <Key ID="str_a3_cfgweapons_arifle_trg21_gl0">
   <Original>TRG-21 EGLM 5.56 mm</Original>
   <English>TRG-21 EGLM 5.56 mm</English>
   <Czech>TRG-21 EGLM 5,56 mm</Czech>
   <French>TRG-21 EGLM 5,56 mm</French>
   <German>TRG-21 EGLM 5,56 mm</German>
   <Italian>TRG-21 EGLM 5,56 mm</Italian>
   <Polish>TRG-21 EGLM 5,56 mm</Polish>
   <Portuguese>TRG-21 EGLM 5.56 mm</Portuguese>
   <Russian>TRG-21 EGLM 5,56 мм</Russian>
   <Spanish>TRG-21 EGLM 5,56 mm</Spanish>
 </Key>

Исправлено, можно закрывать!

PR9INICHEK
All these errors are already covered here :)
http://feedback.arma3.com/view.php?id=24124

Corrected. Please test after the next update.

What about http://feedback.arma3.com/view.php?id=18529 ?

Hello,

thank you for pointing out the incorrections as well as suggesting changes. Our dev team will look into it.

Have a nice day.

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Fixed in the dev version. When one Zeus is controlling a unit, another Zeus won't be able to take over it.

Soo... any progress on fixing it yet? It's been quite some time since I reported this.

Hello Killzone Kid,

thank you for submitting! I am resolving this issue for now but if the problem reappears, I can reopen it anytime.

Thank you.

today both buttons work again

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Master85 is right. Object is returned correctly, but it's deleted before scripted executed by execVM starts. Use 'call' instead.

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Master85, I thought so as well. I was just a little curious as to why it works differently to the others.

Killzone_Kid, thanks for that. I guess I'll have to work around it. How did you go about implementing it?

@h0rs deal with the deleted entity in the scope of event handler

Just tested. curatorObjectDeleted correctly returns the entity deleted.

some guesswork:
At some point - probably after the eventhandler code has finished or in the next frame - the object gets deleted and all object references return null.
You're using execVM to execute "objectDeleted.sqf", i.e. it gets executed in scheduled space, so it's possible that its execution gets delayed and the object reference returns null.
Try to stay in unscheduled space (i.e. call your script) or pass a value (e.g. a string) and not an object reference to your spawned/execVM'ed script.

Im going to test this as soon as BIS fix server browser REMOTE button

so scripts\hooks\objectDeleted.sqf is called but output is <null> ?

Correct :)

_object = _this select 1;

should it be

_object = _this select 0;

in scripts\hooks\objectDeleted.sqf?

Sorry, copypaste error. Yes it still does not work as 0.

I had it at 1 because I was trying to figure out what the hell was wrong.

Modified my original report to reflect that :)

Workaround: to avoid name conflict use name convention with more than 5 letters or avoid use name convention like "z1,z2,z3...etc". Use Targetone, Targettwo...etc instead.

Maybe z1, z2, z3...etc explode after 20 seconds because you have a trigger in mission that setDamage to them after 20 seconds?

class Item2

		{
			position[]={25733.234,12.011079,23427.238};
			a=0;
			b=0;
			interruptable=1;
			age="UNKNOWN";
			name="destructor";
			expCond="time > 20";
			expActiv="z1 setdamage 1; z2 setDamage 2; z3 setDamage 1; z4 setDamage 1";
			class Effects
			{
			};
		};

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Yep you are right.

I have had several conflicts with names in some respawn functions that I believed were related.

Case solved.

Triada, I have kept your suggestions. After the next update, please feel free to check this again and submit a ticket if you find any more mistakes. Thank you!

Чувак, прежде чем предлагать назвать это снарядом, почитай как называются боеприпасы для РПГ, для пушек, а потом предлагай! Твоих школьных представлений об этом не достаточно.

Downvoted, "Снаряд" is wrong name for RPG ammo!!! "Снаряд", is the name for the flight part of cannon ammo only! Full name for cannon ammo is "выстрел". Military term is always was the "выстрел", only girls and childrens name it "снаряд".