Yes but how to pass the paa to setparticleparams:
particleSource setParticleParams
[
[

		particleShape,			/* String */
		particleFSNtieth,		/* Number */
		particleFSIndex,		/* Number */
		particleFSFrameCount,	/* Number */
		particleFSLoop			/* Optional - Number. Default: 1 */

],
animationName, /* String */
particleType, /* String - Enum: Billboard, SpaceObject */
etc
];

I thought setParticleParams (and drop) would only take a p3d as input. I searched through many pbos but can't find a snow p3d or way of using the above "a3\data_f\snowflake4_ca.paa" texture in a particle script. Excuse me taking up your time.

Yes I saw you updated the biki thanks a lot KK. Quick question - is there a particleshape equivalent to the texture "a3\data_f\snowflake4_ca.paa" that can be used in setParticleParams?

Thanks KK - excuse my ignorance in the context of BIS_fnc_setRain how do I reference the (presumably) first frame in the sequence of snowflake4_ca.paa? Like this?
// texDropCount isn't documented from what I can see.

Ok I've amended this ticket. My apologies for wasting your time - it was my mistake - I still had a mod loaded that caused the water splash particle/decal issue.
This morning I tested the function on 40+ maps with different texture scaling and settings and the function works perfectly and no snow impact water effect.

Any news on the addition of UPnP support for Listen or Ded servers ?

You are correct there is more than one issue here. FYI I also cleared the Appdata A3 Launcher folder. (first backed up the presets and other settings.) to force reacquisition/repair of these Launcher files. I also cleared the Steam Apps Common Redistributables folder to force reacquire (C:\Program Files (x86)\Steam\steamapps\common\Steamworks Shared\_CommonRedist). This seemed to also resolve a C++ lib problem in C:\Program Files (x86)\Steam\steamapps\common\Steamworks Shared\_CommonRedist\vcredist. Once I had cleared these files - I got Steam to revalidate the local file cache of Steamworks Common Redistributables - Steam then reacquired the above files.

I had the same problem when trying to import a preset from an html file I was sent. I have found the error - the output html file is formatted incorrectly - I edited the html and file now imports!

Agreed - looking at the positive side. Just potentially an issue for someone who isn't aware they fired up more than one copy and then blame A3 for poor performance.

Sorry this was a corrupt game file - reacquired and fixed. Delete ticket please.

@spOOkz - well spotted! The cause of the crash is vehicle respawn.

Ok here are the files. Page file is managed by Windows. No over clocking.

I am more than happy to use the .EXE to help you resolve the issue

In this particular mission I have 15 chained triggers - each trigger activated by the previous one based on differing conditions using condition 'triggeractivated trigname' - is there a limit how many triggers can be chained?

@TakeHomeTheCup - the issue is if an object has been hidden and simulation deactivated with the Show/Hide Object modifier - the object and any marker should not be visible. There are work arounds to this by changing the variable but in the above case this should not be necessary.

There is an associated issue with the Show/Hide Object modifier module. Objects that have been hidden with this module can still be bumped into - i.e. they are invisible but still seem to have a physical presence in game.

Even if you place new sectors down without copy and pasting them - after unlocking a few sectors there is a massive frame rate drop for a few seconds when new sector is unlocked.

It seems to have something to do with the trigger unlock condition. For example I have an unlock logic synched to a sector which in turn is synched to a trigger Blufor. So when Blufor captured the sector the trigger can be used to activate a respawn position and simultaneously trigger the next sector objective. It is this process that seems to causes the freeze up imo.

If all sectors are active at mission start the mission does not freeze up.

Btw when the sector is captured and the unlock triggers a new spawn point and new sector - the screen flashes back to the menu screen very quickly in both cases.

Yep have same issue. Ive seen lots of others comment on forums also with same issue. It possibly has something to do with copy and pasting an existing sector module. Only seems to happen with unlock sequential sectors.

It is exceptionally difficult to test sequential sector missions - missions freeze up as stated above irrespective of the side the player is on or if he is a civilian and outside any sector at the time of the freeze. RPT files don't indicate any cause either.

Update - after some more testing I have discovered the bit that isn't working in Image2PAA. If you drag and drop into the processing list and check the box "Use custom" for output then you get the failed to process notification and Image2PAA cashes. If however you use just use 'Add source directory' then it seems to work fine. Same files being processed and same location.

Started in Steam and as mentioned I validated cache and reacquired +/- 56 files. Still not working - so I decided to delete A3Tools and red/l the massive 1.2 GB or whatever. Really annoying.

Just verified A3 Tools and had to reacquire files. Image to Paa still fails to process files to Paa. Tried image 1024x1024 jpg png and tga. All fail.

I can confirm that Image to Paa isn't working - I have just re downloaded the 1.2 GB of A3 tools and reinstalled and tried again. Same issue. I even tried with multiple different image types (jpg, png, tga) 1024x1024 with bit depths. Same issue - if I run check image list the files are all apparently fine to be processed. But fail on conversion. Please fix. Btw A3 Tools were launched from within Steam if that makes any difference.

Yep I have same issue. Seems its a wide spread one based on forums.

Please upvote this ticket - it's still not fixed - 9 months after logging. BIS need to filter inputs from joystick controllers for certain classes - like infantry movement. No one uses a joystick to move around and as stated above most joysticks don't have a clearly marked center or neutral zone. It should be a simple issue to fix - just look back a year ago - when this issue wasn't an issue!

My previous suggestion allowing users to uncheck inputs from certain devices on each binding class is a good solution.

It's now 5 months since this issue was logged and it seems Adam is quite happy with the current state of double binding key mappings - if a joystick is plugged in. Adam just for fun - reset your keys with a joystick plugged in and then remap 10 random keys. Make sure your joystick throttle is in the up or down position first. Note my comment above about most throttles not having a center 0 position.

This issue only cropped up in the last 6 months.

I have a number of friends who just started playing Arma3 (I've played nearly 5000 hrs) - without exception they all complain about the key mapping process when a joystick is plugged in - "why hasn't someone fixed this?" is the standard question.

Surely it can be reverted? Or better still see my suggestion above. If there is a new key binding system coming that will replace the current process - then please at least let us know so we don't waste any more of our time!

How do these issues not get picked up in testing before the new version goes public? It's these highly annoying and frustrating issues that put a lot pf people off Arma3. Luckily I'm not one of them. But I know a lot of my friends have given up on Arma3 after playing for a few hours simply because they find the game too frustrating. Issues like this are unacceptable in a game like Arma3.

The point is that no one in their right mind is going to use a double bind keyboard + joystick combination for infantry movement - surely BIS should switch off joystick binding for this input category - alternatively add a checkbox option to bind inputs from controllers on each section - common, infantry movement, etc? This would allow us to filter only specific control inputs i.e. keyboard, mouse, joystick, TrackIR, game controller etc. for each section.

And while we are at it - when mapping a joystick preset the inputs for aircraft using a Logitech Extreme 3D are mostly missing and only some are applied for helicopters. So the apply preset or map option needs some work as well.

Since most joysticks don't have a throttle mid point marker or notch - it's very difficult to center the slider. If you can find the slider mid point - it does remove the double binding - but why has this issue cropped up in the new release - we never had this issue before? Is there now a reverse function for planes? This would be useful when moving a plane from a hangar.

@Adam: Joystick has been centered - if it was a simple matter of recalibration I would not have reported the issue. This happens on all machine's using Logitech Extreme 3D Pro and most likely all others joysticks.

This issue was not present in previous A3 releases. Clearly the input detection in Arma3 is now too sensitive and picking up dead zone inputs or it's a USB sensing issue.

Please get this issue fixed urgently.

Nope once stance is set in the VA you can't change it. You have to go to TRY then change the stance then back to VA. Trust me I wouldn't have logged this if I hadn't checked it.

Why would clicking on an asset change the stance?

The other important issue is that it saves the current stance when you save the loadout.

I have been doing a lot of testing and I am convinced that this issue is not mod specific. I am also pretty certain that this has nothing to do with BattleEye - since the no shutdown issue has been present for some months now prior to BE installation.

The mods I am running currently are A3MP (map pack), Drift No fatigue, Jurassic Arma - Raptor Pack and Reduced Weapon Sway. It appears to relate to mod load timing and memory allocation rather than any specific mod. With vanilla Arma3 (no mods) - A3 shuts down fine.

Interestingly I have noticed that Steam In-game Overlay process - gameoverlayui.exe start up is delayed when mods are being loaded and that it takes a longer than normal time to shut down when the Arma3 process is killed or when A3 terminates normally when no mods are running.

< 45 minutes later

Having monitored Steam GameOverlayUI shut down timing it seems this process does not terminate smoothly as indicated above once Steam detects Arma3 process termination. Process monitor indicates multiple attempts to shut down this exec.

So I'm pretty sure after more testing that this issue relates to the GameOverlayUI. If I switch off Steam overlay In-game (Steam>Settings>In-Game>Uncheck box) and then fire up Arma3 with multiple mods - Arma3 appears to shut down normally.

It is possible that the GameOverlayUI process 'stalls' after a lengthy Arma3 start up. The only thing I can think of is that when A3 loads mods there is a start up timing issue due to mod loading time and probably a related memory allocation/address problem.

Anyway hope this is of some help.

I have been doing some testing and it seems to relate to launching Arma3 with mods activated via the launcher, then Alt tabbing back to the desktop from within editor. Cannot replicate issue without mods activated. It might have something to do with delayed write or swapping or file locks.

Arma3 closes down without issue and reliably with mods running if launched via Steam link and same switching process mentioned above.

So if it's most likely a mod issue - I suggest you close this ticket and dup please since it clearly like looking for a needle in a haystack and not a major issue.

Since Take on has this capability it is clear that BIS is planning to include this feature in a DLC. How this will work who knows? The RAV Lifter mod has fully functional ropes and animation. Fast roping used to work reasonably well but apparently the recent DLC has broken it and Raven appears to not be supporting or developing it anymore. So this feature is for me a must have. We just need to push this as a feature - if u agree vote. Upvoted +1000

@SilentSpike certainly is possible. See ASOR gear selector available at a friendly Armaholic near you. In fact many missions makers have been using this as an alternative to VAS and VA because it has this functionality and a virtual bg. Lôôk at the file I uploaded. So vote for this ticket please. It needs fixing.

Thanks - again this is not always practical. I reckon a great solution would be to add a virtual and or customizable background as an option.

@joostSidy thanks - I can easily work around these limitations - but I think this additional functionality would be helpful to those who do not want to script.

Yep I know but its tricky to get say3D to work reliably within an Addaction command for example even using BIS_fnc_MP. I really think ARMA3 needs a native command that can do what CBA_fnc_globalSay3d can do without us having to install CBA framework (I know most people have it installed already).

Also - once the custom texture has displayed correctly in game - subsequent views display the texture correctly. This applies to the editor and MP levels which are restarted.

i.e. if the texture doesn't display the first time the mission is loaded and if you can get the texture to display by moving very close to the textured object or viewing the object with a scope - forcing the object to redraw correctly (get loaded and cached), subsequent previews seem to work correctly. It's the first load that is problem. It looks like this issue is some kind of texture caching/refresh issue.

This is a generic issue (and well known issue) that effects all people who make missions / mods etc. Just look at the forums - everyone experiences custom texture flashing in and out and late / non display of custom textures. This is a known issue - BIS has been aware of it since A2 days. I explained how to recreate the issue - above. It shouldn't be necessary to explain in any further detail.

The issue seems to be much more prevalent when using jpg texture files.

Interestingly if a custom texture is not displaying even at close distances <100m - using binoculars or scope and looking at the object forces the custom texture to display.

This duplicate with 0022389 - I had a problem with submission.

Please close this ticket.

The attached file shows the new respawn point message spamming - when you place the respawn tent. The notification message appears once for each team member as stated. Not sure why you could not reproduce - just open in editor - no mods loaded - Arma3 launched via launcher.

It makes no difference if there is a respawn_west marker or init/description file with mission and respawn type stated. The deployment of a respawn tent spams x no of messages - based on the size of the team.

Audio notification is now not playing at all for some reason. Maybe latest patch changed something. There should be 1 audio notification when deployed.

Thanks a lot Iceman! Not a big issue but would be nice to have fixed.

This problem seems to only be an issue if using CBA - confirmed that CBA RC4 breaks onEachFrame.

There is definitely an issue with sound since the new patch. Ticket 0021246 also relates to this. I've also noticed a deterioration in the general sound quality in Arma3 at 128 sound sources since applying patch (1.32). Sounds a little more rough and a little too much reverb or gravel with multiple sounds playing at the same time. I've also noticed occasionally when shutting down the editor since 1.32 there is a very brief sound that shuts off - almost like its reinitializing sound support. Almost like some sound playback was duplicated and still playing albeit muted in the menu and then becomes audible only after the editor starts to close. Definitely new since 1.32. Anyway sorry bit vague - difficult to describe. Hope this helps in some way.

It seems the only way to stop the headgear being removed is to add "ASIS" i.e. [this,"SIT","ASIS"] call BIS_fnc_ambientAnim; Having done this and then setting - this setVariable ["BIS_enableRandomization", false]; and then adding specified headgear does not stop headgear randomization. The commands only seem to work correctly on Men (story).

I've also noticed issues with Say3D - sound volume drops and then for no reason gets much louder - where sound source (object) is static and player is also stationery. Almost like sound is being duplicated and or competing. These other sound tickets seem to relate: 0020323, 0021208, 0021246.

There is a related issue that is still happening (wasn't present two patches ago) - when a MP game session or the editor is shut down there is avery brief sound (1 sec) of a sound file playing in the background - presumably from the mission that was just loaded - it gets shut off just prior to the menu being loaded. Not sure if this relates only to missions with custom sound files. In any event the sound should not be playing when the editor or MP session shuts down. This could imply there is a larger issue involved.

@TakeHomeTheCup > Sure I can code around these issues but I thought this was a bug reporting site not a forum to discuss work arounds for vanilla faults. Remember the long term survival of Arma relies on attracting noobs and people who aren't coders and don't have the inclination of spending countless hours working around bugs to produce content. They quite rightly expect basic functions like a respawn system to work out of the box.

It is after all one of the most fundamental requirements for the casual player - who probably already make up the bulk of Arma's user base and will become increasingly more important over the years. To ignore these users requirements is very dangerous since BIS stands the risk of alienating them - more importantly their requirements are really fairly basic. Personally I don't this is too much to ask - that after all these years of development that BIS get some basic features like this working solidly and reliably.

@ Killzone Kid > But that's a different ticket you are discussing under this ticket. (I know I shouldn't have referred to it as per comment above - but it does clearly prove and support my standpoint). Wrt that ticket - as it happens I thought it might be the KB - but I think you'll find I mentioned that I tried multiple different kb's. In fact I run a large LAN and tested on all machines which all have different kb's / different mods etc. Even tried with vanilla Arma3 - same thing. This is clearly not an isolated 'sample of one' issue - based on the number of closed but not resolved tickets plus the number of people referring to this and directly / indirectly related issues on the interweb.

@KillZone Kid "a. there is no revive in Arma 3, so if you have problem after being revived, perhaps you should first talk to the maker of the mission you are playing." -Not sure where the revive issue came in - my post is about respawn.

"b. maybe just maybe you have a problem with your keyboard, mechanical or otherwise?" - ??

Good point - if it happens then I'll just stop reporting. Seems like a waste of time in any event.

This strange issue seems to relate to the pathing issue mentioned in ticket 0020349 and the resetting of the launcher to defaults - i.e. clearing all settings in the launcher including addons. After resetting the launcher to defaults the sound issue seems to have been resolved.(?!) This ticket can be closed.

This issue has been fixed. Please close ticket.

What is odd is that the C:\Users\Mike\Documents\Arma dir was created when the Launcher started. I found some Steam Workshop missions had been copied into that folder(?)! Anyway issue has been resolved by resetting the Launcher with no profile selected. Very odd problem.

There is no rpt in the C:\Users\Mike\AppData\Local\Arma 3\ dir.
There is an rpt file in the C:\Users\Mike\Documents\Arma dir - which I have uploaded.

Oddly if I reset the Launcher to defaults (with no addons specified)- it then starts loading addons previously specified in Arma3 prior to 1.26 update. The second rpt file I uploaded refers to the state after Launcher reset to defaults. Note that after defaults have been set in the Launcher (everything cleared) - Arma3 then reads from and writes to the C:\Users\Mike\Documents\Arma 3\missions dir correctly and not the C:\Users\Mike\Documents\Arma folder mentioned in this ticket. So this issue can be resolved partially by resetting the Launcher to defaults. However this does not resolve the associated issue with correct addon loading since I would assume the settings in the launcher should override the settings in Arma3 > Configure > Expansions.

It works fine you need to add the exact path to the mod and then ; with no space after it to work. i.e. C:\Users\Mike\Documents\Arma 3\@CBA_A3;C:\Users\Mike\Documents\Arma 3\@A3MP;etc;etc

And no the latest patch hasn't fixed it. For every ticket that actually gets logged - there are probably 100's of users who experience the same issue.

There seems to be a method that 'fixes' this. This is not an acceptable fix though - the core issues needs resolving. So don't close this ticket as 'resolved'!

If you hold the up and down keys simultaneously for +/-3 secs then left and right simultaneously for 3 secs it clears the auto run/move issue. This 'work around' should help the developers fix the cause of this issue.