Q and E are used for different speeds when you're driving.

Upvoted.
Not thinking about Altis Life or any other random game mode, this still would be a nice, immersive feature.

I don't see how this would help base Arma at all. If this is for Altis Life, then they should mod it in instead of staying as a mission. That won't happen because they won't have the lazy masses if they required a mod download. That is the price you pay for supporting them instead of a superior modded version.

Well the things is, you have vehicles and you have the available Q and E keys - why not make them toggle turn signals to make the cars more interesting?

Kind of biting my lip concerning the topic change as well.

If the object distance is limiting the object from being seen, this would appear to be the intended result? If so, the next question would be, "What or where is the bug or issue requiring further attention?" Should this bug be closed?

The most players in Altis Life only sprint around in shorts while having rifles and rpg's on their backs. I certainly don't think anyone of them would be using their turn signals in a car.

Yes, it would be a nice little thing, but it would hardly be used by players and it is just not necessary for such a game like Arma.

I cannot seem to modify any of the characteristics of flares, using the above fore mentioned script commands or other commands.

However I should make mention, setLightFlareMaxDistance sounds like it will likely obey the player's maximum view distance.

well, the light is an object isn't it?

Confirmed Fixed on Windows 8.1 64bit using

Namespace dbo
Addon source Directory
P:\dbo\dbo_crosser
Path to project folder
P:\

N.B Not P:\dbo\ as per arma 2

Cheers

we've updated the builder around 14 so the fix is was already there when you're trying it I guess. Anyway I'm glad it works ok for you:) THX

Cooper, sorry to be confusing but I've cleaned the log folder and now It works well... very very confusing, anyway the issue was fixed.

Thanks for the log.
Issue is fixed. We'll update the developement branch today.
Will keep you up to date.

https://dl.dropboxusercontent.com/u/64244091/AddonBuilder.rpt

:/ Now it happens to me at the stable branch ... and It has been updated right now, cleaned the AB installation folder and verified the cache and It continuing deleting the source data.

Weird. I'm not able to reproduce. Could you please upload log file (c:\Program Files (x86)\Steam\SteamApps\common\Arma 3 Tools\Logs\AddonBuilder.rpt)?

Hi, update should be done today (it went wrong yesterday). Will update you once it's done. Thx

hi, updated. Fix is there (tested my self).
Thanks for your patience

Cheers
could you update here once we know its safe please

this is todays changelog with no apparent fix

Addon Builder

    Fixed: Crash on first start, default EXE path was not set
    Fixed: On hover issues with buttons (they tried to run away)
    Fixed: Paths to EXEs were not properly initialized after fresh installation, which caused a crash

:)

I'm really sorry for your troubles. Issue is fixed now. Should be released next week. Sorry once again for this stupid bug.

I think that this one can be closed, as after the last Publisher updates it didn't crash anymore. It has different issues, but this is another story.

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

Hello,
could you please upload your crashdump files?
(rpt + bidmp + mdmp) You can search for them with Windows search functionality.

fixed with new commands

https://community.bistudio.com/wiki/ctrlModelDirAndUp
https://community.bistudio.com/wiki/ctrlSetModelDirAndUp

related:

http://feedback.arma3.com/view.php?id=20385
http://feedback.arma3.com/view.php?id=20386

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

ctrlPosition and ctrlSetPosition doesn't use coordinates defined in 'position' attribute, but in 'x', 'y' and 'z' attributes. They are compatible with 2D position, i.e., x=safezoneX;y=safezoneY is top left corner.

To have an object in middle o the screen, use:
class myObject
{
x = 0.5;
y = 0.5;
z = 1.2;
};

Note: ctrlSetPosition is using XZY format because ctrlPosition was using it for years. We decided to to change the order to maintain backward compatibility.

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

ctrlSetPosition for 3d controls broken too.
Ex:
_pos = ctrlPosition ((findDisplay 228) displayCtrl 228);
((findDisplay 228) displayCtrl 228) ctrlSetPosition _pos;
((findDisplay 228) displayCtrl 228) ctrlCommit 0;

(when ((findDisplay 228) displayCtrl 228) - 3d control).
This shouldn't change position, but position changing unpredictable.

related:

http://feedback.arma3.com/view.php?id=20387
http://feedback.arma3.com/view.php?id=20385

fixed with new commands

https://community.bistudio.com/wiki/ctrlModelScale
https://community.bistudio.com/wiki/ctrlSetModelScale

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

related:

http://feedback.arma3.com/view.php?id=20387
http://feedback.arma3.com/view.php?id=20386

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

Probably related to #20690.

Hey,
the Pilot is visible again in the Dev Build (or will be very soon).

OK Now that's funny ... I just tested everything without any mod and the pilot is indeed invisible (scope = 1 though). It seems like Bohemia Interactive and I did the same mistake at the same time lol

upvoted for fixing

It's a bug of GLT Mod 1.22. It's no A3 bug! I already fixed it so please wait for GLT Mod 1.23.

The issue was that B_Pilot_F had scope = 0 because of a wrong class heritage.

hotfix incoming for 1.26 I hope :)

Confirmed.

For now a workaround you can use is to place a rifleman and then edit the mission.sqm, replacing the unit classname "B_Soldier_F" with the classname of the pilot "B_Pilot_F".

Yeap, confirmed.

The Helicopter Pilot is still listed as "Pilot".
But I guess you mean the Jet Pilot? Yeah, noticed that too.

Noticed that too since last update.

AD2001 is right, an example would be the "Hunter" outfit for civilians, which already has a scarf and would make it glitch extremely with another scarf over it.

An option of selecting hats when playing as civilian/FIA/units without helmets would be nice though, but that is a different story.

Duplicate of #1410.

First, I'm pretty sure that's not what a shemagh is.

Second, some uniforms already have that and it would clip into them.

Have you tried http://killzonekid.com/how-to-change-fov-in-arma-the-easy-way/

You can edit your config to change your FOV. The option is not included in vanilla because it messes up scope alignment.

After tinkering around with the config, this issue is caused because the base class for OPFOR divers (O_Soldier_diver_base_F) does not have the selectionPersonality parameter defined.

A very simple custom config addon that adds selectionPersonality = "personality"; to the base class automatically fixes this issue:
http://i.imgur.com/0dqaDxo.jpg

On a side note, the vertex bug with the model itself still has not been fixed.

Issue still remains on 1.46 stable.

Should be fixed in the next dev branch update. Marking as resolved.

Issue still remains on 1.44 stable.

Both bugs are still present on 1.42.

This is still an issue in 1.40 stable. Again, it only affects the CSAT wetsuit.

Also all of the models seem to have a misaligned vertex for the left arm. Whenever the unit uses an animation that flexes the left arm, the vertex clips all the way into the model's chest or stretches into the head when idle.

Wetsuit [NATO] - http://i.imgur.com/szDY7PC.jpg
Wetsuit [CSAT] - http://i.imgur.com/Y8RUbHO.jpg
Wetsuit [AAF] - http://i.imgur.com/mkOzyU8.jpg

Still observed in 1.36 stable. Not a big problem though.

You're right, i checked for myself and i can confirm this too. No matter what face you choose your character to have when using the CSAT wetsuit you will always end up with this face. Other wetsuits allow custom character faces.

I can imagine that's a technical compromise. It's easier to put a hat model on a person model than a tight fitting swimsuit around a seperate face?

Duplicate of http://feedback.arma3.com/view.php?id=20105

Closing as duplicate.

This bug should have a severity of critical, because it basically makes every mission with UAVs unplayable if it also involves a vehicle or a static weapon.

Same thing happens with every other helicopter that has retractable gear.
This has been a problem since the implementation of "RotorLib".

Hello,
the problem has been assigned and is still being worked on. Thank you for your patience and sorry for inconveniences

Also when you connect to an UAV and this uav get destroyed, for the server you are still in the possision you were when you connected or where you were when the uav got destroyed.

This way you current possition is not sent back to the other player, making you invisible to them, and preventing any server script based on your position to be run correctly.

Once you enter a vehicle the server seems to update the position of the player.