Problem confirmed. A discuss about here : http://forums.bistudio.com/showthread.php?153979-camSetDir-is-bugged-please-upvote

We can use setVectorDirAndUp (or setVectorDir) for 3D vector.
Or setDir for azimut angle.

camSetDir takes a vector. The wiki is just wrong. Use setDir for degrees.

Needs to be fixed, just tested and confirmed bug

Mass close.

This crash should be fix in dev version and fix will be in next update of stable version of Arma 3.
When you want try, so you can activate dev version in Steam.
Right click on Arma III in your Steam Library>Properties>Betas>development build
This version may not stable and it can contain more bugs, than normal Arma 3 Alpha version.

Definitely need a module for this

This suggestion was processed by our team and will be looked into. We thank you for your feedback.

this is resolved in 0.57, as suspected it was related to the (read: lack of a) dedicated server binary

Closing as fixed.

We are very sorry, this issue was closed as no-bug.

you complain about arcadish, but then you want a "cover" buttom? seriously?

i though dsilecxy also spoke about how he, who was a real trained marine felt the guns in ArmA 3 the exact same as when he is with a real gun, just because the gun feels more rigid and solid doesn't mean its more arcadish, go get some training and handle a real gun before you complain about those things

We are very sorry, this issue was closed as no-bug.

#716

Duplicate of #716

This issue was processed by our team and will be looked into. We thank you for your feedback.

Not a bug - the current voice samples are merely placeholders.

Once the radio protocol has been finalized, BI will be recording proper voice samples for all factions.

I have a gut feeling, this has been already reported but likely passed over when searching due to misspellings or uncommon title/description. Here it is anyways. (Or maybe the bugs are being automatically closed.)

I also noticed this might be already linked to the latest developer changelog entry "Removed fully script commands: setVehicleInit, clearVehicleInit, processInitCommands."

Some quick work arounds:

1. Modify your map to have 20+ choppers and vehicles.
2. Allow the server to be restarted, however you'll never experience night if the game doesn't sync to real world time.

Those are obviously placeholders because the actual voices haven't been recorded yet <.<

And from the latest SITREP: "The next step is getting our Creative Director Crowe to record the well-known Jayholder voice-overs. Then we're ready to start recording final voice actors."

Of course it's going to change in the future, they posted somewhere that the OPFOR language is not yet localized. This is again the least of their worries as of this stage. EDIT: Here is where they said about localisation: http://alpha.arma3.com/sitrep-0008

An interesting note about OPFOR dialogue: The OPFOR are already coded to speak Takistani. If you don't like hearing them speak English, then you can merge your ArmA2 and ArmA3 directories, and they will speak Takistani. =D

I think it is something very important... Not speaking iranian, but at least with an accent, as in OFP

because it would be retarded for BIS to let pass the OpFor (iran) talking english when they are trying to make an actually good campaign, there has been no game from BIS that used the same voices for BLU and Op

"this is of course gonna change in the future" - How can you know for sure?
I thought the point of the alpha is to report bugs, deficiencies and suggested features so the developers can address them.

Well looking at the randomize scripts, you probably need a delay when you execute setObjectTexture[Global] after the creation.

This is exactly the problem, at the moment I have to spawn scheduled threads that sleep for a second and only then apply needed texture. Before it was even worse with execVM as it sometimes executed randomization script after my scheduled thread overwriting my texture changes.

My suggestion is following: Let us handle randomization ourselves, give us a choice to disable BIS randomization scripts all together, no default texture setting, no nothing, just don't execute anything and let us handle this ourselves. I already provided an easy solution in the ticket. Wrap all inits that have randomization scripts with following code:

init = 'if(({(_this select 0) isKindOf _x} count (missionNamespace getVariable ["BIS_noVehicleRandomization", []])) == 0) then {(_this select 0) execVM "\A3\soft_F\Offroad_01\scripts\randomize.sqf";};';

That's it. If mission designer will need to disable randomization for all Offroads they will just add:

BIS_noVehicleRandomization = ["Offroad_01_base_F"];

This is assumed to be added somewhere on mission init and not during the mission.

Alternatively this can be moved into description.ext and read with getArray(missionConfigFile >> "noVehicleRandomization")

The new vehicle customization should be all over the game, feel free to provide feedback at https://forums.bistudio.com/topic/179469-vhc-vehicle-customization-dev-branch/
If it suits You well, close the issue, please. Thanks a lot for the valuable feedback that made us to do the whole feature.

i dont really understand why people make fun of people like you who dont understand what does "alpha" means, just like that smart annoying kid that make a virus-script that kill everyone in a server because he complained about the game being buggy.

I personally feel pitty for you, you still dont understand that this is of course gonna change in the future, yet you make a ticket on this game.

Well looking at the randomize scripts, you probably need a delay when you execute setObjectTexture[Global] after the creation.

Or are you SaMatra saying this doesn't work, or that setting an "empty texture" does not work?

You might still run into a JIP problem with the above depending on the execution order. Make sure to double check this.

Ok guys, reopening the issue. Since there is a feedback needed, could you please specify what exactly your proposes are so our Encoding master pettka has easier job to do?
Thank you very much!

Well, I think he would have to extend setObjectTextureGlobal/setObjectTexture to work with the built-in textures.

The setVariable workaround is not an option for vehicles created by script (i.e. createVehicle).

Another way would be to extend createVehicle (array) by a new, optional parameter to include a texture index of built-in textures.

SaMatra is right (of course), since setVehicleInit was removed, there is no way to script a properly textured vehicle.

This change is barely useful as you still cannot change vehicle texture right away.

_vehicle = createVehicle ["C_Offroad_01_F", getPos player, [], 0, ""]; _vehicle setObjectTexture [0, ""];

Will not remove first texture. Issue is not solved.

Definitely a step in the right direction. However there needs to be a way to disable the setTexture functionality of a vehicles altogether (exit the script).

Ack that stuff like this is excellent for those who want to drop and play with vehicles/civvies/etc that aren't clones, but this is incredibly frustrating for mission authors.

I recall getting equally pissed off with the randomisation for the PMC DLC in ArmA 2. I'm irritated to see that this is now of a greater scale in ArmA 3, still without a way to nip it in the bud without running another script to override it.

I have added some new functionality that may help:
http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2668894&viewfull=1#post2668894

while i understand why the FIA are having offroads without doors or rear view mirrors, there are some instances were i would like to be able to control that permanently for a mission

related: https://www.youtube.com/watch?v=FhUmIEFXlsQ

related http://feedback.arma3.com/view.php?id=16017

Please for god's sake sort this out!!!! :))

Here is the summary http://killzonekid.com/arma-annoyances-say-no-to-randomize/

I would really prefer to see disabled vehicle color randomization by vehicle classes like suggested in "Additional Information", also it would be better if check would be made on "init" event hander rather than in randomize script itself so it wouldn't even start another script thread with execVM.

C_Offroad_01_F >> EventHandlers:

init = '(_this select 0) execVM "\A3\soft_F\Offroad_01\scripts\randomize.sqf"';

change to

init = 'if(({(_this select 0) isKindOf _x} count (missionNamespace getVariable ["BIS_noVehicleRandomization", []])) == 0) then {(_this select 0) execVM "\A3\soft_F\Offroad_01\scripts\randomize.sqf";};';

i cant vote 1 million times yes on this ticket, but i want to, i really hate to see that the same vehicle will spawn with a different color every time i restart the game

Stable hasn't updated

Ah great thanks, will marked as resolved on DEV and coming to next stable.

Unable to reproduce. Can someone confirm this is still happening with repro?

Unable to reproduce on development branch 1.29.127079.

It seems to be working correctly.

Reproduced on stable branch 1.28.127008.

Added video.

Thank you. Could you also test this on DEV branch to confirm it has been fixed?

This is standard Windows behaviour when applications are run with different permisions ("Run as administrator"). For example, if you run Arma3 as admin and it is in focus, it will not pass on key combos to background apps that were not run as admin.

This is not a bug with the game.

This has been fixed.

If the issue is still reproducable for you, please request that this ticket be re-opened. (Either PM me on the forums or create a ticket referencing this one.)

It's a lot better now, thanks!

Improved in today's dev build, now around 25-35 fps average rather than 18. Still needs work though.

When flying over the airfield I noticed that the lighting seemed more 'flickery' than yesterday; rendering and then disappearing for a second in various areas.

Also, only about a quarter of Agia Marina is lit up, is it meant to be like that?

i tried dev build today and wow huuuge drop in fps....went straight back into the stable branch! upvoted

I made a video that shows that bug.
http://www.youtube.com/watch?v=4SOA2IPgJiw

Reproduced and confirmed in current dev build.

same here

Can confirm this. 50-60 FPS during day, down to 12 at night.

i7 3.4 GHz
GTX 680
8 Gb RAM
Win7 64

Same problem here. Development branch Hardly playable at night. Mostly noticeable in air station Stratis (but still very low FPS everywhere on the map). Sometimes game even "freezes" for few seconds (not a MP sync issue). I haven't noticed any performance issues during daytime.

os: updated Windows 7 64bit
cpu: Intel Core i5-2500K
gfx: nVidia GTX560Ti with driver version 314.22

60FPS day, 25FPS night, 13-18FPS with NVGs on.

Can confirm this. 60 FPS in day and 18 at night same scene... Switching dynamic lighting or HDR to 'low' makes no difference (assume it's a lighting problem due to the latest updates).

Hope don't have to change the lighting back to how it was... It looks so much better now in towns :)

EDIT: Also noticed GPU usage was significantly lower at night.

Agreed. Changes to the dynamic lighting in dev build 0.55.104588 have caused severe performance issues - particularly around Agia and the airport where there are a lot of lights.

Steamworks integration is in the pipeline, as confirmed by Dwarden.

Mass closing ancient tickets with no activity for > 12 months; assume fixed or too trivial.

If this issue is still relevant in current dev build, please re-post.

Related: remove the lock-on icon. It enables to quickly scan a huge area for enemy vehicles that may be hard to spot visually.

#5669

Duplicate of #5669