Alpha texture shadow does not work very reliably and is always a compromise, this cannot be fixed/changed on our side

Hi Dedman,

I just checked the latest dev-branch and it seems to be working now. Thanks.

I've had this happen recently with a Marid as well. I'm not sure if it's because I'm using a Track IR or not. I think I was crouching to dodge enemy fire at the time.

If that doesn't help please send us the crashfiles so we can see what is happening around the time of the crash.
You can get those by pressing the left button on the screen you send a screenshot of, or use this https://community.bistudio.com/wiki/Crash_Files

Please follow the steps here: https://community.bistudio.com/wiki/Arma_3:_Unusual_process_exit#0xC0000005_-_ACCESS_VIOLATION
If that doesn't help please send us the crash report, so we can see what is happening at the time of the crash: https://community.bistudio.com/wiki/Crash_Files

Most of your crashes actually have the same symptoms, something is overwriting memory.
I would love to fix this, I have seen dozens of crash reports with this exact stuff and I have absolutely no clue why or how it happens. I'd love to finally fix this mess.

Please switch to perf/prof branch, these are newer binaries and will make crash analysis a bit easier.
Also it would be great if I could get a full dump, but these are very huge (compress well with 7z though) and will need to be uploaded somewhere else (for example google drive)
If you load this mod: https://github.com/dedmen/ArmaFullDump/releases/tag/1.1 Arma will create full crashdumps several GB in size that contains all the information.
The normal crashdumps are just minidumps that omit alot of useful information

Okey, for your 08-01_19-15-26 crash. That was in our audio system.
Again pointing to audio like was my first guess.

I don't know exactly why but now that the server runs version [2.04.147719] the fadeSound-command seems to work as usual again.

Man something really is seriously wrong.
What looks like memory corruption crashes all over the place.
I'll look closer into some of these, but most look like just random memory garbage crashes.

When I go to join and play in an online match it always crashes before I'm fully in the game.

Thanks @dedmen!

Error was only present on profiling branch, fix is in profiling v16 this week

im getting the same problem and have tryed everything to fix it

Could just use preprocessor #ifdef to hide them on server, either with __IS_DEDICATED__ or with command line parameter macro

additional note (pointing out the source issue even more):
a "steerable parachute" is also categorized as a "vehicle", responding only to the analog bindings for steering - making the confused state of the TRACKED VEHICLES not responding at all to the bindings even more noticeable.

Find the crach report attached

Nevermind. I had filePatching disabled on my client for some reason even though I enabled it last night while testing these things. Arma... Or maybe an user based error :P

It gives me this error message now:

Closed on request of author.

Thanks @blackfisch!! :)

crash should be fixed, yes, and thanks for reporting

In T160224#2225214, @BIS_fnc_KK wrote:

rev 148073

Also, what you are doing makes no sense, I mean saving mission config in profile namespace, same as saving display for use later. Mission config exists only while mission is running. New mission, new config instance. On top profile namespace is serialized and loaded on game start. way before any mission is started, so mission config saved to profile namespace will give you exactly nothing after you left mission.

Would either of you happen to have an example batch file for the PBO packing?

You have some file writing issues probably, antivirus, windows permissions, something else

rev 148073

I have been able 100% reproduce the remoteControl issue, but getting it to happen with selectPlayer eludes me. I've never seen it myself, so perhaps the person reporting it to me was wrong.
The scripts are all in the init.sqf.

we can add consistent functionality via alt syntax

Hey neuromancer,

Yes.
Non-full mag in main muzzle and non-full mag in secondary muzzle:

• only reloads the main muzzle, secondary muzzle stays untouched.
• If secondary muzzle is selected only hand gesture is played, none of the weapon anims play (as the main muzzle mag gets reloaded). If main muzzle is selected all anims play correctly

so to summarise, if current muzzle can be reloaded it gets reloaded with proper animation and that’s the end of reloading. otherwise it keeps searching for a muzzle to reload, and if it is not current muzzle, it reloads it without animation, and this is where reload ends? Sounds like it should just put another magazine into current muzzle, I think the idea was to mimic reload key press.

Had this issue in Malden after adding those rocks manually via the EDEN Editor as regular objects (Not simple objects) but all simulations disabled on them.

might be related: https://feedback.bistudio.com/T160213

This ^^^ I forgot how I did it years ago, exactly that packing pbo then launching server, takes seconds

In T160204#2224716, @Ezcoo wrote:

I've just closed server exe, as I didn't think about that it could make a difference. When it comes to the bat file, my main motivation was to shorten the iteration cycle for editing multiplayer missions so having to close and restart the client kind of is the actual issue. When you have e.g. Tanoa as map, it takes a moment for the game to fire up even with the game on an ultra fast SSD drive.

I downloaded and tested the provided mission, as well as tried some more details with the following result:

Oh. There is addMagazineAmmoCargo.
My bad.

I've just closed server exe, as I didn't think about that it could make a difference. When it comes to the bat file, my main motivation was to shorten the iteration cycle for editing multiplayer missions so having to close and restart the client kind of is the actual issue. When you have e.g. Tanoa as map, it takes a moment for the game to fire up even with the game on an ultra fast SSD drive.

This issue is also much more likely to occur when there is lots of AI about and client/server fps is low. Due to the difficulty of reproducing this bug I can't tell if it is caused by client or server issues.

This issue is still present.

rev. 148055

Do you exit the server all the way to the main screen before shutting down the server or just close server exe? Also why not create bat file which will launch both server and client, adding a line that will shut any if still running prior to relaunching?