Page MenuHomeFeedback Tracker

[Steam Alpha 0.5.102571] Second loading always the same duration
Closed, ResolvedPublic


When loading showcases, previewing or continuing missions in editor, there are two loading bars, the first one seems to be working correctly, but the second one seems to always advance in 15 segments of which each lasts 1 second. {F16697}


Legacy ID
Steps To Reproduce
  1. Open editor
  2. Place a playable Rifleman
  3. Preview mission
  4. Observe that the second loading of the loading bar will advance in 15 segments which will last 1 second each
Additional Information

Steam ArmA 3 Alpha - 0.5.102571

Since I had access to Alpha builds on Steam from the initial upload there, I did not notice this in earlier builds, the second loading bar was variable in duration and usually really short. It used to increase in length if I had put myself in a helicopter with the flying status, but not as long and fixed in duration it is now.

Hardware seems to have no effect, ArmA3 on my system is currently on an SSD, but there is no difference in the second loading bar even if I put it on the slower HDD. Amount of RAM also has no effect on the duration of the second loading bar. The first bar is slower on the HDD and almost instant on the SSD as expected and in case I put tons of units on the map. The second one is literally always at 15 seconds.

While I have no clue what's actually going on during these two loading bars, the second one gives me an impression as if there is some sleep()'s or something of 1 second interval during the second loading of the loading bar.

I've attached a DxDiag as this might be relevant to this report.

Event Timeline

Sniperwolf572 edited Additional Information. (Show Details)
Sniperwolf572 set Category to Engine.
Sniperwolf572 set Reproducibility to Always.
Sniperwolf572 set Severity to Minor.
Sniperwolf572 set Resolution to Fixed.
Sniperwolf572 set Legacy ID to 3703856426.May 7 2016, 10:27 AM

Update on this. This seems to be actually related to the weapon the unit has, specifically the MX series of rifles.

Updated repro steps:

  1. Open editor
  2. Place yourself as Civilians > Men > Civilian
  3. Preview
  4. Observe that the second loading of the loading bar is very short
  5. Return back to the editor
  6. Edit Civilian you created
  7. Add the following to the initializiation field: this addWeapon "arifle_MX_F"
  8. Preview
  9. Observe that the second loading of the loading bar takes around 15 seconds
  10. Return back to the editor
  11. Edit the Civilian you created
  12. Clear the initialization field, replace with the following: this addWeapon "arifle_Khaybar_F"
  13. Preview
  14. Observe that the second loading of the loading bar is short again

In addition to all "arifle_MX..." weapons, "arifle_SDAR_F" also causes this issue.

FortuN added a subscriber: FortuN.May 7 2016, 10:27 AM
FortuN added a comment.Mar 6 2013, 8:22 PM

Confirmed. Its a lot slower loading when playing with this weapons.

Jeza added a subscriber: Jeza.May 7 2016, 10:27 AM
Jeza added a comment.Mar 6 2013, 8:51 PM

Also noticed this straight off the bat.

When it's loading I fix that by alt+tabbing to desktop and then switching back to game. Works for me and I'm pretty sure it will work for you too guys.

Same here. Performance increase from this last update but this was the negative result.

Can confirm that alt-tab out when the "slow loading" is working. But very irritating doing this every time!

Yep, same issue here and only alt-tab can speed this up.

God. This has bothered me since release. I was like "Why doesn't ARMA 3 do like ARMA 2, and not reload the entire damn thing every time?!".

Never tried with Iranian troops before. Just did, and it loads INSTANTLY like it should.

God this has been annoying. Took forever to do anything.

Okay, I've had enough, so I've written this script, which redeems the problem until BIS fixes it.

Here's the script:

It works in both singleplayer and multiplayer.

What it does:
Before the mission is loaded, it makes a snapshot of the weapons of all blufor units, and removes their weapons.
This causes the loading to go instant, like it should, because no one is using the rifles causing the bug anymore.
Once the loading has completed, the script rearms the units from the snapshots it made prior to removing them.

How to use it (As I know some people may not be in to scripting):

  1. The mission must be saved.
  2. Navigate to c:\Users\USERNAME\Documents\Arma 3 Alpha\missions\YOUR_MISSION_NAME.Stratis.
  3. Hit the Alt key. A menu should appear at the top of Explorer. Go to Tools > Folder options. Go to the "View" tab. Untick "Hide extensions for known file types".
  4. Right click in the folder and create a new text document.
  5. Name it "instant_loading.sqf" (without the quotes).
  6. Open the file in notepad, and copy the contents from the paste above into the file you just created.
  7. Save it and close it.
  8. Create another text file called "init.sqf" (without the quotes).
  9. Open the file in notepad, and put (including quotes and everything):

execVM "instant_loading.sqf";

  1. Save and close the file.
  2. Go back to the editor, and hit save just to be sure.
  3. Click Preview, and enjoy instant loading.

That "Instant_Loading" seems to disable the AT to get rockets for BLUFOR

There. Fixed it. New version up.

Note that AI units will now say "Out of ammo" when the mission starts, but ATs, etc. won't lose theirarockets.

Thanks, now though i found out that it disables silencers put on soldiers.

If you have in the initfield for a soldier like: this addprimaryweaponitem "muzzle_snds_H"; Then they will not get the silencer. Tested without the script and then it worked again.

This problem has been around since release. It seems like the second loading bar is just an empty animation, the actual loading is already finished.

The first loading bar initializes the mission. The second loads the game world. The problem is that it reloads the entire game world every time, if you use specific weapons.

This is no longer an issue on "arifle_MX..." series of rifles as of 0.51.103078.
It is still an issue with "arifle_SDAR_F".

This is also no longer an issue on "arifle_SDAR_F" as of 0.53.103342.

As far as I'm concerned, this can be closed as fixed. :)

Closing as per request.