R3vo/Sandbox – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 1: Line 1:
{{TOC|side|0.8||y}}
{{TOC|side}}
If you have ever wondered why you scenario is running so badly, performance profiling is the way to find it out. It allows you to find bottlenecks and slow code by capturing a "slow" frame.
The captured data can then be viewed and analysed.


Startup parameters are command line interface(CLI) arguments that go after the executable's name in order to set options; e.g {{hl|arma3_x64.exe -window}} to start the game in {{Link|#window}}ed mode.
== Getting the correct Version ==
Profiling is enabled in the following {{arma3}} versions
* arma3profiling_x64.exe - '''Part of the Performance Profiling Build'''
* arma3diag_x64.exe - '''Part of the Development Build'''


{{Feature|informative|
Read [[Arma_3: Steam Branches]] for a guide on how to access these branches.
* Startup parameters' ''names'' are case-insensitive - e.g {{hl|-WINDOW}} and {{hl|-window}} are identical.
* Spaces in parameter values must be wrapped in quotations. e.g. {{hl|c= "-profiles=E:\Arma 3\Profiles"}} or {{hl|c= -profiles="E:\Arma 3\Profiles"}}
* Most of the following parameters can be set with the [[Arma 3: Launcher]].
}}


{{TOC|subtoc
{{Feature|informative|It is recommended to use the '''Performance Profiling Build''' (arma3profiling_x64.exe) for performance profiling because:
|content=
* Has tools that might not make it into development build
* {{Link|#Steam}}
* Has all the profiling related commands that ''arma3diag_x64.exe'' has
* {{Link|#Windows}}
* Its performance is closer to the default ''arma3_x64.exe''}}
* {{Link|#Path Definition}}
* {{Link|#Display Options}}
* {{Link|#Game Loading Speedup}}
* {{Link|#Profile Options}}
* {{Link|#Misc.}}
* {{Link|#Client Network Options}}
* {{Link|#Server Options}}
* {{Link|#Performance}}
* {{Link|#Developer Options}}
}}


== Steam ==
[[File:Performance_Profiling_01.png|thumb|diag_captureFrame sample output]]
[[File:Performance_Profiling_02.png|thumb|diag_captureFrame sample output]]
[[File:Performance_Profiling_03.png|thumb|diag_captureFrame sample output]]


# Choose the game in Steam\Library
== Frame Capturing ==
# Right click on the game
There are several commands that allow you to capture a frame.
# Select properties
* [[diag_captureFrame]]
# Hit "Set launch options"
* [[diag_captureSlowFrame]]
* [[diag_logSlowFrame]] - not available in Arma 3 :(
* [[diag_captureFrameToFile]]
In most cases you do not want to capture any or all frames, you just want to capture "slow" frames. A slow frame is a frame that takes longer than the average frame and slows down the game. If you target is that the scenario should run at 30 FPS then a frame can only take


; Example
== How to Use ==
: {{hl|c= -nosplash "-mod=test;x\test;c:\arma 3\test2"}}


# Run a mission
# Execute a scripted command <sqf inline>diag_captureSlowFrame ["total", 0.3];</sqf> using any means ([[Arma 3: Debug Console|Debug Console]], mission radio trigger...)
# Once a slow frame is detected, a window will open
# In the window you will be able to browse a lot of performance-related data, which can be interesting
# To export the gathered information for sharing with others:
## Select Main Thread (if not selected yet)
## Press the Copy button
## Open an external text editor
## Paste the text into a new file
## Save the file


== Windows ==


When working with shortcuts, cmd launch options: there is max characters limit for the executing line, use '''-par''' (see: [[Startup Parameters Config File]]) to avoid it.
[[File:Performance_Profiling_04.png|thumb|diag_captureFrame sample output with custom subtree]]
== Creating Your Own Subtree ==


{| class="valign-top"
When Profiling Per-Frame Eventhandlers (PFH), [[diag_captureFrame]] only shows one blob called siFEH that contains all PFH's so you can't see what part of that is caused by your PFH.<br>
! Startup Command Line
You can create your own subtree inside siFEH by wrapping your function call inside a [[isNil]] CODE statement like this:<br>
! parameters file
Turn your old call which may look like this:
|-
<sqf>
|
addMissionEventHandler ["EachFrame", {
arma3_x64.exe "-par=D:\Arma 3\Startup Parameters.txt"
call myPFHFunction
|
}];
-skipIntro
</sqf>
-noSplash
-enableHT
-hugePages
-noLogs
|}


Into something like this:
<sqf>
addMissionEventHandler ["EachFrame", {
isNil { call myPFHFunction } // isNil creates the subtree
}];
</sqf>


== Path Definition ==
Now when you run [[diag_captureFrame]] inside of siPFH you will have a subtree called gsEva and behind that you can see the first line of code inside the isNil statement.<br>
It will only show a part of the first line of that code so you should put something descriptive into the [[isNil]] statement.<br>
You can use the same to create a subtree for any function you like. This will also work inside [[Scheduler#Scheduled_Environment|Scheduled]] ([[spawn]]ed) scripts. <br>
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.


There are a few basics to keep in mind when defining path as part of a parameter.


=== Spaces ===
== Notes ==
----


The path '''and''' -profiles need to be enclosed with quotes if it contains spaces, e.g {{hl|c= "-profiles=E:\Arma 3\Profiles" or -profiles="E:\Arma 3\Profiles"}}.
* 0.3 is a time in second used to determine what duration of a frame you consider abnormal, and first such frame will be captured.
* 0.3 is definitely something you should not see in a normal game.
* If you do not capture any frames with 0.3, try lowering it to 0.2 or 0.1.
* If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.


=== Relative vs Absolute ===
----


You can define most, if not all path in both ways.
== See Also ==


; Relative
* [[Code Optimisation]]
: {{hl|c= -profiles=Profiles}}
* [[Mission Optimisation]]


; Absolute
: {{hl|c= "-profiles=E:\Arma 3\Profiles"}}


The relative path is normally based on the game main folder, where the exe resides in. However when you use -profiles, some commands use this path defined there as base.
[[Category:Arma Scripting Tutorials]]
 
 
== Display Options ==
 
=== window ===
----
 
Displays {{arma3}} windowed instead of full screen. Screen resolution / window size are set in [[arma3.cfg]].
 
; Example
arma3_x64.exe -window
 
=== posX ===
----
Sets the default X Position of the Window.
 
; Example
arma3_x64.exe -posX=50
 
=== posY ===
----
 
Sets the default Y Position of the Window.
 
; Example
arma3_x64.exe -posY=50
 
=== adapter ===
----
 
Sets the default Video Adapter.
 
; Example
arma3_x64.exe -adapter=MISSING_AN_EXAMPLE
 
 
== Game Loading Speedup ==
 
=== noSplash ===
----
 
Tells the engine to bypass the splash screens on startup of {{arma3}}.
 
{{Feature|informative|
Real speed-up gained with this is likely to be negligible in {{arma3}}, as the loading screens are handled in parallel with the game data being loaded, and the loading itself takes quite long thanks to the amount of data needed.
}}
 
; Example
arma3_x64.exe -noSplash
 
=== skipIntro ===
----
 
Disables world intros in the main menu permanently.
 
{{Feature|informative|
Real speed-up gained with this is likely to be negligible in {{arma3}}, as the loading screens are handled in parallel with the game data being loaded, and the loading itself takes quite long thanks to the amount of data needed.
}}
 
; Example
arma3_x64.exe -skipIntro
 
=== world ===
----
 
Select a world loaded by default. For faster game loading (no default world loaded and world intro in the main menu, ''only at game start'', disabled): -world=empty.
 
; Example
For faster game loading (no default world loaded and world intro in the main menu, ''only at game start'', disabled)
arma3_x64.exe -world=empty
Load Altis
arma3_x64.exe -world=Altis
 
=== worldCfg ===
----
 
Inits a landscape by the given world config.
 
 
== Profile Options ==
 
=== name ===
----
 
Sets the profile name.
 
; Example
arma3_x64.exe -name=PlayerOne
 
=== profiles ===
----
 
Location of user-profile folder.
 
If a custom path is set, default files and folders (logFiles, AnimDataCache, DataCache, SteamPreviewCache....) located by default in {{hl|%LocalAppData%/Arma 3}} will be created in that new location.
 
However, old files will stay in the old location and will not be copied.
 
; Example 1
arma3_x64.exe -profiles=C:\arma3\Profiles
 
; Example 2
arma3_x64.exe -profiles=Profiles
 
Example 2 create a folder called ''Profiles'' in the {{arma3}} root directory
 
{{Feature|important|
The Windows user account needs write access in the chosen location.
}}
 
=== unit ===
----
 
Parameter passes a unit's ID number to the binary, translates to ''<nowiki>https://units.arma3.com/my-units#?unit=<number></nowiki>''
 
; Example
arma3_x64.exe -unit=1337
 
 
== Misc. ==
 
=== buldozer ===
----
 
Starts [[Buldozer]] mode.
 
; Example
arma3_x64.exe -buldozer
 
=== noLand ===
----
 
Starts with no world loaded. (Used for [[Buldozer]])
 
; Example
arma3_x64.exe -noLand
 
=== noSound ===
----
 
Disables sound output.
 
; Example
arma3_x64.exe -noSound
 
=== doNothing ===
----
 
Engine closes immediately after detecting this option.
 
; Example
arma3_x64.exe -doNothing
 
=== mod ===
----
 
Loads the specified [[Arma: Mod Folders|mod folders]]. Multiple folder need to be separated by a semicolon.
 
; Example 1
arma3_x64.exe -mod=test;x\test;c:\arma3\test2
 
* '''"test"''' is located in the {{arma3}} installation folder ("Arma 3\test") (relative path)
* '''"x\test"''' is in the installation folder ("Arma 3\x\test") (relative path; subfolder)
* '''"c:\arma3\test2"''' is in "c:\arma3\test2" (absolute path)
 
; Example 2
On Windows
arma3_x64.exe "-mod=test;x\test;c:\arma3\test2"
 
; Example 3
On Linux. Note the additional backslash in front of the semicolon
arma3_x64.exe "-mod=test\;x\test\;c:\arma3\test2"
 
{{Feature|informative|
"Relative path" starts from, or is rooted at, the directory from where the {{arma3}} executable has been started and is not always the same where the executable is, like in betas.
Usually this is the same as the installation path and the same as what is written in Windows registry, but if you copy or symlink the necessary file and folders, you may have different roots.
It is useful when having multiple dedicated servers.
}}
 
 
== Client Network Options ==
 
=== connect ===
----
 
Server IP to connect to.
 
; Example
arma3_x64.exe -connect=168.152.15.147
 
=== port ===
----
 
Server port to connect to.
 
; Example
arma3_x64.exe -port=1337
 
=== password ===
----
 
Server password to connect to.
 
; Example
arma3_x64.exe -password=1337abc
 
=== host ===
----
 
Start a non-dedicated multiplayer host.
 
; Example
arma3_x64.exe -host
 
 
== Server Options ==
 
=== setUpHost ===
----
 
Start the game in the setup server display. Works with the client exe. See [[:File:a3_startup_parameters_createhost.png|reference image]]
 
; Example
arma3_x64.exe -setUpHost
 
=== server ===
----
 
Start a [[Arma 3: Dedicated Server|dedicated server]]. Not needed for the dedicated server exe.
 
; Example
arma3_x64.exe -server
 
=== port ===
----
 
Port to have dedicated server listen on.
 
; Example
arma3server_x64.exe -port=1337
 
=== pid ===
----
 
File to write the server's PID (process ID) to.
 
* The file is removed automatically when the exe is stopped
* Only works for dedicated servers
 
; Example
arma3server_x64.exe "-pid=C:\My Server\PID.txt"
 
=== ranking ===
----
 
Allowing you to output ranking information or otherwise know as player stats to a file.
 
The windows user account would need permissions to write to the folder of choice.
 
Output sample:
<syntaxhighlight lang="cpp">
class Player1
{
name = "PlayerName";
killsInfantry = 71;
killsSoft = 3;
killsArmor = 5;
killsAir = 5;
killsPlayers = 0;
customScore = 0;
killsTotal = 84;
killed = 3;
};
</syntaxhighlight>
 
; Example
arma3server_x64.exe "-ranking=C:\arma3\ranking.log"
 
=== netlog ===
----
 
Enables multiplayer network traffic logging. For more details see [[ArmA:_Server_configuration|server configuration]].
 
; Example
arma3server_x64.exe -netlog
 
=== cfg ===
----
 
Selects the [[basic.cfg|Server Basic Config file]]. Config file for server specific settings like network performance tuning.
 
{{Feature|important|
Using this parameter overrides the game config ({{hl|Documents\Arma 3\Arma3.cfg}}); use at your own risk on clients.
}}
 
; Example
arma3server_x64.exe "-config=C:\My Server\basic.cfg"
 
=== config ===
----
 
Selects the [[Arma 3: Server Config File|Server Config File]]. Config file for server specific settings like admin password and mission selection.
 
; Example
arma3server_x64.exe "-config=C:\My Server\config.cfg"
 
=== profiles ===
----
 
Path to the folder containing server profile.
 
* By default, server logs are written to server profile folder
* If folder doesn't exist, it will be automatically created
* Does not work on Linux, no profile will be created or used - instead, remove this parameter and the profile will be created in {{hl|~/.local/share/Arma 3 - Other Profiles}}
 
; Example
arma3server_x64.exe "-profiles=C:\My Server\profiles"
 
=== bePath ===
----
 
By default BattlEye will create ''BattlEye'' folder inside server profile folder. With -bePath param it is possible to specify a custom folder.
 
; Example
arma3_x64.exe -bePath=C:\MyBattlEyeFolder
 
=== ip ===
----
 
Command to enable support for Multihome servers. Allows server process to use defined available IP address. (b1.57.76934)
 
; Example
arma3_x64.exe -ip=145.412.123.12
 
=== par ===
----
 
Command to read startup parameters from a file. For more details see [[Startup_Parameters_Config_File|Startup parameters config file]].
 
; Example
arma3_x64.exe "-par=C:\Users\Player\Games\Arma 3\Arma 3 Parameter Files\par_common.txt"
 
=== client ===
----
 
Launch as client (console). Useful for [[Arma 3: Headless Client|headless clients]].
 
; Example
arma3_x64.exe -client
 
=== loadMissionToMemory ===
----
 
Server will load mission into memory on first client downloading it. Then it keeps it pre-processed pre-cached in memory for next clients, saving some server CPU cycles.
 
; Example
arma3server_x64.exe -loadMissionToMemory
 
=== autoInit ===
----
 
Automatically initialize mission just like the first client does.
 
The server config file (server.cfg) must contain <syntaxhighlight lang="cpp" inline>Persistent = 1;</syntaxhighlight> otherwise the {{hl|autoInit}} parameter is skipped.
 
{{Feature|important|
This will break the [[Arma 3: Mission Parameters]] function, so do not use it when you work with mission parameters, only default values are returned!
}}
 
; Example
arma3server_x64.exe -autoInit
 
=== serverMod ===
----
 
Loads the specified sub-folders for different server-side (not broadcasted to clients) mods.
 
* Separated by semi-colons
* Absolute path and multiple stacked folders are possible
* In Linux multiple folders arguments need the following separation syntax: -serverMod=mod1\;mod2\;mod3
 
; Example
arma3server_x64.exe "-serverMod=myAwesomeMod;anotherAwesomeMod"
 
=== disableServerThread ===
----
 
Option to disable the server send messaging thread in case of random crashing (may also decrease performance of server on multicore CPUs)
 
; Example
arma3_x64.exe -disableServerThread
 
=== bandwidthAlg ===
----
 
Set to 2 to use a new experimental networking algorithm that might be better than the default one.
 
; Example
arma3_x64.exe -bandwidthAlg=2
 
{{ArgTitle|3|limitFPS|{{GVI|arma3|1.98}}}}
 
Limits the server FPS to the provided value in 5..1000 FPS range (default 50).
 
; Example
arma3_x64.exe -limitFPS=300
 
{{ArgTitle|3|networkDiagInterval|{{GVI|arma3|1.30}}}}
 
Polls the status of bandwidth, traffic and similar data every X seconds. Since {{GVI|arma3|2.18}} is also logs size and count of [[publicVariable|public variables]] when using the ''Profiling binary''.
 
; Example
arma3_x64.exe networkDiagInterval=10
 
 
== Performance ==
 
=== maxMem ===
----
 
Overrides memory allocation limit to a certain amount (in megabytes).
 
{{Feature|important|
Until {{GVI|arma3|2.14}} there was a bug on the Linux server binary where it parses the maxMem value as a signed integer, therefore making 4096 interpreted as a negative value;
in order to avoid this issue, use values like {{hl|2047}}, {{hl|4095}}, {{hl|8191}}, {{hl|16383}}, {{hl|32767}} (2048 -1, 4096 -1 etc).
}}
 
1024 MiB is a hard-coded minimum (anything lower falls back to 1024). The maximum is influenced by your operating system (any value over the maximum will be reverted to this value):
* 32-bit Windows + 32-bit game: 2047
* 64-bit Windows + 32-bit game: 3071
* 64-bit Windows + 64-bit game: (physical memory * 4) / 5
 
'''Without the -maxMem parameter the engine attempts to set this parameter internaly to a reasonable value often defaulting to max values as described above.''' The file cache is always excluded from the virtual address limit, see our developers blog: https://www.bistudio.com/blog/breaking-the-32-bit-barrier.
 
{{Feature|informative|
Note that setting maxMem to 2000 does not mean that the game will never allocate more then 2000 MiB. It says that the game will do everything in its power to not cross this limit. In general, it makes sense not using this parameter at all and only resort to it in case you experience issues with memory.'''
}}
 
; Example
arma3_x64.exe -maxMem=4096
 
=== maxVRAM ===
----
 
Defines video memory allocation limit to number (in megabytes).
 
* Minimum value is 128 MiB (anything lower falls back to 128)
* The value is ignored (under DX11) if engine properly detected VRAM size, minus 20% reserve with ceiling limit 300MB max
* Use to resolve e.g. Windows problem: http://support.microsoft.com/kb/2026022/en-us?p=1
 
; Example
arma3_x64.exe -maxVRAM=4096
 
=== maxFileCacheSize ===
----
 
{{GVI|arma3|2.14}} Sets the default filecache size (when files are loaded from disk, they are cached in RAM. If the cache is full, the oldest file is thrown out).
 
{{Feature|informative|
* Default size was either {{hl|maxMemory - 448 MB}} or if you had more than 2 GB of memory available to {{arma3}}, it would be limited to max 2048 MB.
* Setting lower than 1 GB is not recommended.
* Minimum possible value is 512 MB
}}
 
; Example
arma3_x64.exe -maxFileCacheSize=2048
 
=== noCB ===
----
 
Turns off multicore use. It slows down rendering but may resolve visual glitches.
 
; Example
arma3_x64.exe -noCB
 
=== CPUCount ===
----
 
Change to a number less or equal than numbers of available cores. This will override auto detection (which equate to native cores).
 
The best way to simulate dual core on quad core is to use -cpuCount=2 when you run the game and then change the affinity to 2 cores to make sure additional cores can never be used when some over-scheduling happens. It might be also possible to set the affinity in the OS before you launch the process, that would work as well.
 
; Example
arma3_x64.exe -exThreads=8
 
=== exThreads ===
----
 
Change to a number 0,1,3,5,7. This will override auto detection (which use 3 for dualcore and 7 for quadcore).
 
All file operations go through a dedicated thread. This offloads some processing from the main thread, however it adds some overhead at the same time.
 
The reason why threaded file ops were implemented was to serve as a basement for other threads ops. When multiple threads are running at the same time, OS is scheduling them on different cores.
Geometry and Texture loading (both done by the same thread) are scheduled on different cores outside the main rendering loop at the same time with the main rendering loop.
 
{| class="wikitable sortable valign-top"
|+ Ex(tra)threads table
! Parameter
! class="unsortable" | Description
|-
! Number !! Geometry loading !! Texture loading !! File operations
|-
! 0
| 0 || 0 || 0
|-
! 1
| 0 || 0 || 1
|-
! 3
| 0 || 1 || 1
|-
! 5
| 1 || 0 || 1
|-
! 7
| 1 || 1 || 1
|-
|}
 
; Example
arma3_x64.exe -exThreads=7
 
=== malloc ===
----
 
Sets the particular memory allocator to be used. Significantly affects both performance and stability of the game. [[Arma 3: Custom Memory Allocator|More details]].
 
; Example
arma3_x64.exe -malloc=someMalloc
 
=== hugePages ===
----
 
Enables hugepages with the default memory allocator ([[Arma 3: Custom Memory Allocator|malloc]]) for both client and server.
 
; Example
arma3_x64.exe -hugePages
 
=== enableHT ===
----
 
Enables the use of all logical CPU cores for parallel tasks processing. If your CPU does not support Hyper-Threading or similar technology, this parameter is ignored.
When disabled, only physical cores are used.
 
{{Feature|informative|
Note that enabling this parameter may slightly improve or harm the performance depending on a scenario.
This parameter may be overridden by -cpuCount so if you want to use the maximum number of CPU cores use "-enableHT" without "-cpuCount".
}}
 
; Example
arma3_x64.exe -enableHT
 
{{ArgTitle|3|setThreadCharacteristics|{{GVI|arma3|2.10}}}}
 
Registers the game's executable as "Game" in Windows for performance improvements.
{{Feature|warning|This flag can freeze the whole Operating System if running Windows Server!}}
 
; Example
arma3_x64.exe -setThreadCharacteristics
 
 
== Developer Options ==
 
=== noPause ===
----
 
Allow the game running even when its window does not have focus (i.e. running in the background)
 
; Example
arma3_x64.exe -noPause
 
{{ArgTitle|3|noPauseAudio|{{GVI|arma3|2.10}}}}
 
Keeps audio running in background while tabbed out. Should be used together with '''-noPause''' to work correctly
 
; Example
arma3_x64.exe -noPauseAudio
 
=== showScriptErrors ===
----
 
Introduced to show errors in scripts on-screen. In [[:Category:Eden Editor|Eden Editor]], script errors are always shown, even when this parameter is not used.
 
; Example
arma3_x64.exe -showScriptErrors
 
=== debug ===
----
 
Enables more verbose error logging. See [[Arma 3: Debug Mode]]
 
; Example
arma3_x64.exe -debug
 
=== noFreezeCheck ===
----
 
Disables the freeze check. It creates otherwise max 4 dumps per game run in total - 2 per distinct freeze. Similar to [[Crash Files]].
 
; Example
arma3_x64.exe -noFreezeCheck
 
=== noLogs ===
----
 
Be aware this means none errors saved to RPT file (report log). Yet in case of crash the fault address block info is saved.
 
More details {{Link|http://forums.bistudio.com/showthread.php?159155-quot-nologs-quot-may-improve-performance-no-stuttering-read-details|here}}.
 
; Example
arma3_x64.exe -noLogs
 
=== noFilePatching ===
----
 
Ensures that only PBOs are loaded and NO unpacked data.
 
{{Feature|informative|
Since {{GVI|arma3|1.50}} this was replaced in favor of the {{hl|-filePatching}} parameter.
}}
 
; Example
arma3_x64.exe -noFilePatching
 
{{ArgTitle|3|filePatching|{{GVI|arma3|1.50}}}}
 
Allows the game to load unpacked data. For more info see [[CMA:DevelopmentSetup]]
 
; Example
arma3_x64.exe -filePatching
 
=== init ===
----
 
Run scripting command once in the main menu. For example to start a certain SP mission of choice automatically. See also [[playMission]]. The Mission has to reside in the "arma3\Missions" folder, NOT the user directory.
 
; Example
arma3_x64.exe -init=playMission["","Test.VR"]
 
=== <path>\mission.sqm ===
----
 
Load a mission directly in the editor. Example: {{hl|"C:\arma3\users\myUser\missions\myMission.intro\mission.sqm"}}
 
=== autotest ===
----
 
Loads automatically a series of defined missions and on error writes to a log file.
 
The parameter can be used to automatically run a series of test missions. For example FPS measurement or scripting validation.
 
* The game runs in special mode. It runs all missions from the given list.
* If any mission fails (ends with other than END1), it is logged into the [[arma.RPT|rpt file]] (search: <autotest).
* In case of any fail, the game also returns an errorlevel to DOS. This can be used to issue an notification by a secondary application.
 
; Launch {{arma3}} with: {{hl|c= "-autotest=c:\Arma 3\autotest\autotest.cfg"}}
 
The {{hl|autotest.cfg}} looks like:
<syntaxhighlight lang="cpp">
class TestMissions
{
class TestCase01
{
campaign = "";
mission = "autotest\TestCase01.VR"; // relative path to the arma directory
};
class TestCase02
{
campaign = "";
mission = "C:\arma3\autotest\TestCase02.VR"; // absolute path
};
};
</syntaxhighlight>
 
{{Feature|important|If {{hl|-profiles}} is used, the relative path is relative to the specified profile path.}}
 
; Example
arma3_x64.exe -autotest=c:\arma3\autotest\autotest.cfg
 
; RPT entry:
<syntaxhighlight lang="html">
<AutoTest result="FAILED">
EndMode = LOSER
Mission = autotest\TestCase01.VR
</AutoTest>
</syntaxhighlight>
 
If possible use simple worlds, like VR, to keep the loading times short. The [[startLoadingScreen|loading screen]] command might be useful as well to speed up task that need no rendering.
 
=== beta ===
----
 
Loads the specified beta sub-folders. This allows use of beta build w/o disabling in-game mod/extension management (in UI menu).
 
* Separated by semicolons
* Absolute path and multiple stacked folders are possible
* '''In Linux''' multiple folders arguments need the following separation syntax: {{hl|c= arma3_x64.exe "-mod=betamod1\;betamod2\;betamod3"}}
 
=== checkSignatures ===
----
 
Provide a thorough test of all signatures of all loaded banks (PBOs) at the start of the game. Only the stored sha1 values are verified with signatures/keys. Output is in {{hl|.rpt}} file.
 
; Example
arma3_x64.exe -checkSignatures
 
=== checkSignaturesFull ===
----
 
Same as above, but checks every byte of the file content, and therefore not only verifies signatures, but also verifies file integrity.
 
; Example
arma3_x64.exe -checkSignaturesFull
 
=== d3dNoLock ===
----
 
Doesn't lock the VRAM.
 
; Example
arma3_x64.exe -d3dNoLock
 
=== d3dNoMultiCB ===
----
 
D3D uses Single Constant Buffers instead of Multiple Constant Buffers.
 
; Example
arma3_x64.exe -d3dNoMultiCB
 
<!--
=== crashDiag ===
----
 
Extra crash-logging in performance binary, added on v18 (https://forums.bistudio.com/topic/160288-arma-3-stable-server-154-performance-binary-feedback/?p=2979101)
 
; Example
arma3_x64.exe -crashDiag
-->
 
=== debugCallExtension ===
----
 
Logs extension calls in the rpt log like this: [[File:arma3-startup_parameter_debugCallExtension_output.png]]
 
; Example
arma3_x64.exe -debugCallExtension
 
=== command ===
----
 
Creates {{Link|https://en.wikipedia.org/wiki/Named_pipe|named pipe}} "\\.\pipe\name" for receiving predefined set of commands. See [[Arma 3: Named Pipe]].
 
; Example
arma3_x64.exe -command=MyFancyPipeName
 
{{ArgTitle|3|language|{{GVI|arma3|2.04}}}}
 
Starts client with preferred language. See {{Link|Stringtable.xml#Supported Languages}} for a list of supported languages. '''Case-sensitive!''' (className column)
 
{{Feature|informative|{{GVI|arma3|2.18}} made the parameter work properly.}}
 
; Example
arma3_x64.exe -language=German
 
{{ArgTitle|3|preprocDefine|{{GVI|arma3|2.06}}}}
 
Defines a macro and optionally its value. Multiple macro can be defined by using this parameter multiple times.
 
; Example 1
arma3_x64.exe -preprocDefine="CMD__MACRONAME=MACROVALUE"
arma3_x64.exe -preprocDefine=CMD__MACRONAME
arma3_x64.exe -preprocDefine=CMD__MACRO1 -preprocDefine=CMD__MACRO2
 
; Example 2
arma3_x64.exe -preprocDefine=MACRO
 
The macro name '''will''' start with {{hl|CMD__}}, the engine automatically adds the prefix if it is not present ({{hl|CMD__MACRO}}).
 
{{ArgTitle|3|dumpAddonDependencyGraph|{{GVI|arma3|2.14}}}}
 
dumps {{Link|https://en.wikipedia.org/wiki/Graphviz|Graphviz}} text file into the RPT directory with a graph of all addon dependencies ({{hl|requiredAddons}})
 
; Example
arma3_x64.exe -dumpAddonDependencyGraph
 
 
[[Category: Startup Parameters]]

Revision as of 17:20, 25 October 2024

If you have ever wondered why you scenario is running so badly, performance profiling is the way to find it out. It allows you to find bottlenecks and slow code by capturing a "slow" frame. The captured data can then be viewed and analysed.

Getting the correct Version

Profiling is enabled in the following Arma 3 versions

  • arma3profiling_x64.exe - Part of the Performance Profiling Build
  • arma3diag_x64.exe - Part of the Development Build

Read Arma_3: Steam Branches for a guide on how to access these branches.

ⓘ
It is recommended to use the Performance Profiling Build (arma3profiling_x64.exe) for performance profiling because:
  • Has tools that might not make it into development build
  • Has all the profiling related commands that arma3diag_x64.exe has
  • Its performance is closer to the default arma3_x64.exe
diag_captureFrame sample output
diag_captureFrame sample output
diag_captureFrame sample output

Frame Capturing

There are several commands that allow you to capture a frame.

In most cases you do not want to capture any or all frames, you just want to capture "slow" frames. A slow frame is a frame that takes longer than the average frame and slows down the game. If you target is that the scenario should run at 30 FPS then a frame can only take

How to Use

  1. Run a mission
  2. Execute a scripted command diag_captureSlowFrame ["total", 0.3]; using any means (Debug Console, mission radio trigger...)
  3. Once a slow frame is detected, a window will open
  4. In the window you will be able to browse a lot of performance-related data, which can be interesting
  5. To export the gathered information for sharing with others:
    1. Select Main Thread (if not selected yet)
    2. Press the Copy button
    3. Open an external text editor
    4. Paste the text into a new file
    5. Save the file


diag_captureFrame sample output with custom subtree

Creating Your Own Subtree

When Profiling Per-Frame Eventhandlers (PFH), diag_captureFrame only shows one blob called siFEH that contains all PFH's so you can't see what part of that is caused by your PFH.
You can create your own subtree inside siFEH by wrapping your function call inside a isNil CODE statement like this:
Turn your old call which may look like this:

addMissionEventHandler ["EachFrame", { call myPFHFunction }];

Into something like this:

addMissionEventHandler ["EachFrame", { isNil { call myPFHFunction } // isNil creates the subtree }];

Now when you run diag_captureFrame inside of siPFH you will have a subtree called gsEva and behind that you can see the first line of code inside the isNil statement.
It will only show a part of the first line of that code so you should put something descriptive into the isNil statement.
You can use the same to create a subtree for any function you like. This will also work inside Scheduled (spawned) scripts.
But using this method to "subtree" a function with return values requires a little bit of trickery to get the return value out.


Notes

  • 0.3 is a time in second used to determine what duration of a frame you consider abnormal, and first such frame will be captured.
  • 0.3 is definitely something you should not see in a normal game.
  • If you do not capture any frames with 0.3, try lowering it to 0.2 or 0.1.
  • If it triggers too early, before the main slowdown happens, increase it to a higher value, e.g. 1.0.


See Also

Retrieved from "https://community.bistudio.com/wiki?title=User:R3vo/Sandbox&oldid=369992"