R3vo/Sandbox – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
 
(102 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{TOC|side}}
{{TOC|side}}
{| class="wikitable"
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.
! colspan=5 |Arma 3 Server Configuration Overview
The captured data can then be viewed and analysed.
|-
 
! Topic !! colspan=4 | Pages
== Getting the correct Version ==
|-
Profiling is enabled in the following {{arma3}} versions
! Setup
* arma3profiling_x64.exe - '''Part of the Performance Profiling Build'''
| [[Arma 3: Dedicated Server]] || [[Arma 3: Dedicated Server (Chinese Simplified)]] || [[Arma 3: Dedicated Server (Chinese Traditional)]]
* arma3diag_x64.exe - '''Part of the Development Build'''
|-
 
! Files
Read [[Arma_3: Steam Branches]] for a guide on how to access these branches.
| [[Arma 3: Server Config File]] || [[basic.cfg]] || [[server.armaprofile]]
 
|-
{{Feature|informative|It is recommended to use the '''Performance Profiling Build''' (arma3profiling_x64.exe) for performance profiling because:
! Other
* Has tools that might not make it into development build
| [[Multiplayer Server Commands]] || [[Arma 3: Mission voting]] || [[Arma 3: Headless Client]]
* Has all the profiling related commands that ''arma3diag_x64.exe'' has
|}
* Its performance is closer to the default ''arma3_x64.exe''}}
 
== Frame Capturing ==
There are several commands that allow you to capture a frame.
* [[diag_captureFrame]]
* [[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.
 
== How to Use ==
# 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
 
== Capture Frame UI ==
[[File: arma3-capture frame ui overview.png]]
 
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
# {{Wiki|TODO}}
 
== External Viewer ==
* chrome://tracing
* https://ui.perfetto.dev/
 
[[File:Performance_Profiling_04.png|thumb|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.<br>
You can create your own subtree inside siFEH by wrapping your function call inside a [[isNil]] CODE statement like this:<br>
Turn your old call which may look like this:
<sqf>
addMissionEventHandler ["EachFrame", {
call myPFHFunction
}];
</sqf>
 
Into something like this:
<sqf>
addMissionEventHandler ["EachFrame", {
isNil { call myPFHFunction } // isNil creates the subtree
}];
</sqf>


This article deals with the '''basic.cfg''', the name means nothing, and can be called anything. The real name is determined by the [[Arma 3: Startup Parameters|-cfg]] command line option when launching the dedicated server or the game executable - in other words '''it also works for clients'''. When you do not provide a name, the default <tt>Arma3.cfg</tt> file is loaded located in the user profile folder.
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.


In this configuration file you should configure your server's connectivity, mainly for performance tuning.


= Performance Tuning Options =
== Notes ==


There are also some parameters that can be used to fine-tune network performance. You can add following entries to arma.cfg (the main Armed Assault configuration file)
* 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.


{| class="wikitable"
== Scopes ==
{| class="wikitable sortable"
|-
! Technical Name !! Descriptive Name !! Description
|-
| Main
|
|
|-
| total
|
|
|-
| fsPHa
|
|
|-
| winMs
|
|
|-
| dlcSim
|
|
|-
| steamCbk
|
|
|-
| input
|
|
|-
| wSimu
|
|
|-
| docSim
|
|
|-
| wSimDisp
|
|
|-
| MFDManager
|
|
|-
| wDisp
|
|
|-
| EventPrcs
|
|
|-
| gsEva
|
|
|-
| gbFrm
|
|
|-
| memLo
|
|
|-
| siScr
|
|
|-
| scrVM
|
|
|-
| wsSet
|
|
|-
| sLand
|
|
|-
| simSW
|
|
|-
| cLWObj
|
|
|-
| oTemp
|
|
|-
| FPres
|
|
|-
| waitSnd
|
|
|-
| job
|
|
|-
| sound
|
|
|-
| ssAdv
|
|
|-
| snCmt
|
|
|-
| play
|
|
|-
| ARTCpl
|
|
|-
| rendr
|
|
|-
| drwVi
|
|
|-
| txHLi
|
|
|-
| txPMM
|
|
|-
| dsr2t
|
|
|-
| wPrep
|
|
|-
| dPr
|
|
|-
| fmiRun
|
|
|-
| fmiWait
|
|
|-
| fmiMDrw
|
|
|-
| fmiSIns
|
|
|-
| wPrepFtr
|
|
|-
| clPrp
|
|
|-
| oPrep
|
|
|-
| sceAC
|
|
|-
| oSplt
|
|
|-
| sceACTA
|
|
|-
| sceACPrx
|
|
|-
| lodUL
|
|
|-
| PrxObj
|
|
|-
| manAn
|
|
|-
| ppdOT
|
|
|-
| flProx
|
|
|-
| PrxObjTransport
|
|
|-
| oSoSL
|
|
|-
| oSoJE
|
|
|-
| oSoJE1
|
|
|-
| oSoJE2
|
|
|-
| oSo1OFOv
|
|
|-
| oSo1ON
|
|
|-
| sceCLsHSH
|
|
|-
| prpAMCt
|
|
|-
| oSoJEw
|
|
|-
| pDrwFNP
|
|
|-
| oSoSLu
|
|
|-
| lPGCl
|
|
|-
| pdDrw
|
|
|-
| lDGnd
|
|
|-
| lGSMM
|
|
|-
| recCB
|
|
|-
| mtPmj
|
|
|-
| cuDrw
|
|
|-
| prepT
|
|
|-
| drwCB
|
|
|-
| oPasD
|
|
|-
| o1Drw
|
|
|-
| lckDnBf
|
|
|-
| prpTx
|
|
|-
| inst
|
|
|-
| stpSctnTL
|
|
|-
| o1ShV
|
|
|-
| scSVI
|
|
|-
| oPas3
|
|
|-
| sssmC
|
|
|-
| sbDrw
|
|
|-
| aniMt
|
|
|-
| ppSSSM
|
|
|-
| drwROM
|
|
|-
| drwIn
|
|
|-
| wDraw
|
|
|-
| lDPGT
|
|
|-
| oSDrw
|
|
|-
| oPasO
|
|
|-
| lDSky
|
|
|-
| swRdr
|
|
|-
| ppSWDD
|
|
|-
| swRdGeom
|
|
|-
| swRdGeomVB
|
|
|-
| swFillV
|
|
|-
| oPasA
|
|
|-
| ppShrpn
|
|
|-
| lDWat
|
|
|-
| oPas2
|
|
|-
| o2Drw
|
|
|-
| oPas5
|
|
|-
|-
! Parameter !! Default !! Description
| o5Drw
|
|
|-
|-
| <tt>MaxMsgSend = 128</tt> || <tt>128</tt> || aximum number of packets (aggregate messages) that can be sent in one simulation cycle ("frame"). Increasing this value can decrease lag on high upload bandwidth servers.
| EDraw3D
|  
|  
|-
| MEventPrcs
|
|
|-
| cLGSY
|
|
|-
| stpAll
|
|
|-
| stpCB
|
|  
|-
|-
| <tt>MaxSizeGuaranteed = 512</tt> || <tt>512</tt> || Maximum size (payload) of guaranteed packet in bytes (without headers). Small messages are packed to larger packets (aggregate messages). Guaranteed packets (aggregate messages) are used for non-repetitive events like shooting.
| stpTxtCS
|  
|  
|-
|-
| <tt>MaxSizeNonguaranteed = 256</tt> || <tt>256</tt> || Maximum size (payload) of non-guaranteed packet in bytes (without headers). Small messages are packed to larger packets (aggregate messages).  Non-guaranteed packets (aggregate messages) are used  for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag.
| stpUAVsCS
|  
|  
|-
|-
| <tt>MinBandwidth = 131072</tt> || <tt>131072</tt> || Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded.
| ppHDRCL
|  
|  
|-
|-
| <tt>MaxBandwidth = 200000 || <tt>UNKOWN</tt> || Bandwidth the server is guaranteed to never have (in bps). This value helps the server to estimate bandwidth available.
| ppGSB
|  
|  
|-
|-
| <tt>MinErrorToSend = 0.001</tt> || <tt>0.001</tt> || Minimal error to send updates across network. Using a smaller value can make units  observed by binoculars or sniper rifle to move smoother at the trade off of increased network traffic.
| ppDOF
* Example: A unit 1km (distance d = 1km) from the player with MinErrorToSend = 0.001 (METS = 0.001) would send an update when that unit moves 50m (error value E = 50).
|  
* Formula: d = sqrt[(20E)/METS] ; 1000 = sqrt[(20E)/0.001] -> E = 50
|  
* In reality, other factors about the object are taken into effect as well according to a weighted scale.
* When the error value (E) between the master copy of an object (whoever "owns" the object) and a client's perceived/simulated copy of the same object >= MinErrorToSend (METS), a network update message will be sent for it.
|-
|-
| <tt>MinErrorToSendNear = 0.01</tt> || <tt>0.01</tt> || Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well.
| ppGlwNw
* When using MinErrorToSend alone, for small values of distance (d) the frequency of high errors (E) would cause excessive network messages that are not necessary but could negatively impact FPS.
|  
* Too large of a value for METSN can prevent timely desirable network update messages which can result in units appearing to "warp"
|  
[http://forums.bistudio.com/showthread.php?125396-Arma-2-OA-beta-build-84984&p=2103305&highlight=minerrortosend#post2103305 Detailed explanation of METS and METSN by Suma]
|-
|-
! colspan="3" | Networking Tuning Options
| ppGLu
|
|
|-
|-
| stpCBUpd
|
|  
|  
  class sockets
  {
    maxPacketSize = 1400;
  };
| <tt>1400</tt>
| Maximal size of packet sent over network. This '''can be set for both''' client-to-server and server-to-client(s) independently''! {{Feature|important|Only use in the case your router or ISP enforces lower packet size and you have connectivity issues with the game.}} ''Desync might happen if used '''MaxSizeGuaranteed/MaxSizeNonguaranteed values over the maxPacketSize'''.
|-
|-
| <tt>MaxCustomFileSize = 1024</tt> || <tt>UNKNOWN</tt> || Users with custom face or custom sound larger than this size are kicked when trying to connect.
| ppQWt
|  
|  
|-
| ppCMAA
|
|
|-
| hudDr
|
|
|-
| 3DEN_UI_OnDraw
|
|
|-
| 3DEN_PrepareDraw
|
|
|-
| clObL
|
|
|-
| 3DEN_Drawing
|
|
|-
| stpTxtGS
|
|
|-
| txt2D
|
|
|-
| mapDr
|
|
|-
| mapSeaAndNormal
|
|
|-
| mapPM
|
|
|-
| lndPM
|
|
|-
| MapObjectsPrepTask
|
|
|-
| mapSeaAndNormalDraw
|
|
|-
| mapCntDraw
|
|
|-
| mapObjectsDraw
|
|
|-
| mapForestShape
|
|
|-
| mapGrid
|
|
|-
| drwFn
|
|
|-
| dtTot
|
|
|-
| wFram
|
|
|-
| 3dSwp
|
|
|-
| preLd
|
|
|-
| preLV
|
|
|-
| actObjPrld
|
|
|-
| hashChk
|
|
|-
| sSim
|
|
|-
| enfWorkShort
|
|
|-
| updAttPos
|
|
|-
| oSo1AN
|
|
|-
| prpAMCf
|
|
|-
| prpAMCSlt
|
|
|-
| prpSDM
|
|
|-
| locL
|
|
|-
| mapSeaAndNormalWork
|
|
|-
| mapObjectsPrepWork
|
|
|-
| drwIdxPrm
|
|
|-
| oSo3
|
|
|-
| lsCVB
|
|
|-
| oSo5
|
|
|-
| oSo2CL
|
|
|-
| oSo1AF
|
|
|-
| Visualize
|
|
|-
| visul
|
|
|-
| txMLo
|
|
|-
| oSo2Srt
|
|
|-
| oSoSdw
|
|
|-
| prpAMCbsi
|
|
|-
| prpAMCp
|
|
|-
| Render
|
|
|-
| bgD3D
|
|
|-
| stpTxtVS
|
|
|-
| ppHBAOPlus
|
|  
|}
|}


= Example Configuration File =
<sqf>
 
private _ctrlTV = ctrlparent (_this select 0) displayCtrl 101;
<pre>
MinBandwidth = 131072; // Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072
MaxBandwidth = 10000000000; // Bandwidth the server is guaranteed to never have. This value helps the server to estimate bandwidth available.
 
MaxMsgSend = 128; // Maximum number of messages that can be sent in one simulation cycle. Increasing this value can decrease lag on high upload bandwidth servers. Default: 128
MaxSizeGuaranteed = 512; // Maximum size of guaranteed packet in bytes (without headers). Small messages are packed to larger frames. Guaranteed messages are used for non-repetitive events like shooting. Default: 512
MaxSizeNonguaranteed = 256; // Maximum size of non-guaranteed packet in bytes (without headers). Non-guaranteed messages are used for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256
 
MinErrorToSend = 0.001; // Minimal error to send updates across network. Using a smaller value can make units observed by binoculars or sniper rifle to move smoother. Default: 0.001
MinErrorToSendNear = 0.01; // Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well. Default: 0.01
 
MaxCustomFileSize = 0; // (bytes) Users with custom face or custom sound larger than this size are kicked when trying to connect.
</pre>
 
= Notes and Comments=
The greatest level of optimization can be achieved by setting the MaxMsgSend and MinBandwidth parameters. For a server with 1024 kbps we recommend the following values:
    MaxMsgSend = 256;
    MinBandwidth = 768000;
While connected to the dedicated server, you can use the [[Multiplayer Server Commands|admin command]] {{ic|#monitor}} to monitor server resource usage. (You have to be logged in as or voted as game admin to do this.) The server never runs at more than 50 fps. When running slower, it always uses all available CPU processing power to maintain the smoothest possible gameplay. When running at less than 20 fps, you can consider the server overloaded – the mission currently played is probably too complex for given server. If you see the server is not using bandwidth that it could use, you can try increasing values ''MaxMsgSend'' and ''MinBandwidth''.
 
----
Official Response to the meaning of a Simulation Cycle
{{Feature|quote| "Simulation cycle" is what makes "frame" in a normal game.
However, as there is no rendering on server, we cannot talk
about frames, and we talk about simulation cycles instead.
One cycle break down approximately to:
simulate all units AI
simulate all units movement including collisions and physics
detect visibility between units
simulate scripts and FSMs
receive network updates about remote entities
send network updates about what has changed to the server (if on client) or to other clients (if on server)|BI Forums|http://forums.bistudio.com/showthread.php?p{{=}}1363400}}
 
== Related comments by Suma ==


'''Does a 10x times lower MinErrorToSend mean also 10x times the traffic from the server?'''
private _export = "{| class=""wikitable sortable"""  + endl + "|-" + endl;
_export = _export + "! Technical Name !! Descriptive Name !! Description";


In extreme case (provided you have enough bandwidth available) it might mean 10x more traffic. I think it should be easy to measure the effect, using #monitor command or external tools.
private _fnc_logChilden =
{
    params ["_path"];


'''Do lower MinErrorToSend take more CPU processing on the server?'''
    for "_i" from 0 to ((_ctrlTV tvCount _path) - 1) do
    {
        private _text = _ctrlTV tvText (_path + [_i]);
        _text = _text splitString " " select 0;


Yes, some more processing, as there are more messages to handle, but I do not expect anything major.
        if !(_text in _export) then
        {
            _export = _export + endl + "|-" + endl + "| " + _text + endl + "| " + endl + "| ";
        };


'''Do basic.cfg settings on clients also have an effect? Like for the player entity itself or the AI under his command (AI local to the player)?'''
        if (_ctrlTV tvCount (_path + [_i]) > 0 ) then
        {
            [_path + [_i]] call _fnc_logChilden;
        };
    };
};


Yes, it affects what client sends to a server as well, but in a different way (the error computation is different, it is not considering any camera position).
[[]] call _fnc_logChilden;


'''Is that correct, that every message contains motion update (or other update) ONLY FOR ONE object? So when we have 1000 AIs near player, and we wish to have update 50x per second for all AIs, so we must set MaxMsgSend to higher than 1000?'''
copyToClipboard (_export + endl + "|}" + endl);
</sqf>


The aggregate message contains multiple logical messages, which are related to multiple objects.
== See Also ==


'''Related comment by Suma'''
* [[Code Optimisation]]
* [[Mission Optimisation]]


MinErrorToSendNear is used differently from MinErrorToSend.
When computing the error for MinErrorToSend, the error is divided by (distance_in_m/20m)^2.
Because of this, when MinErrorToSend is small enough so that distant units move smooth,the near units move "supersmooth" (the updates are sent even when the movement is so smooth, it makes no gameplay difference).
MinErrorToSendNear gives a way to give another absolute (not distance dependent) limit ("never send update smaller than 1 cm, even if MinErrorToSend would allow it to be sent").


{{GameCategory|arma3|Multiplayer}}
[[Category:Arma Scripting Tutorials]]

Latest revision as of 18:23, 4 November 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

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.

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

Capture Frame UI

arma3-capture frame ui overview.png

  1. 🚧
    TODO: this must be updated.
  2. 🚧
    TODO: this must be updated.
  3. 🚧
    TODO: this must be updated.
  4. 🚧
    TODO: this must be updated.
  5. 🚧
    TODO: this must be updated.
  6. 🚧
    TODO: this must be updated.
  7. 🚧
    TODO: this must be updated.
  8. 🚧
    TODO: this must be updated.
  9. 🚧
    TODO: this must be updated.

External Viewer

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.

Scopes

Technical Name Descriptive Name Description
Main
total
fsPHa
winMs
dlcSim
steamCbk
input
wSimu
docSim
wSimDisp
MFDManager
wDisp
EventPrcs
gsEva
gbFrm
memLo
siScr
scrVM
wsSet
sLand
simSW
cLWObj
oTemp
FPres
waitSnd
job
sound
ssAdv
snCmt
play
ARTCpl
rendr
drwVi
txHLi
txPMM
dsr2t
wPrep
dPr
fmiRun
fmiWait
fmiMDrw
fmiSIns
wPrepFtr
clPrp
oPrep
sceAC
oSplt
sceACTA
sceACPrx
lodUL
PrxObj
manAn
ppdOT
flProx
PrxObjTransport
oSoSL
oSoJE
oSoJE1
oSoJE2
oSo1OFOv
oSo1ON
sceCLsHSH
prpAMCt
oSoJEw
pDrwFNP
oSoSLu
lPGCl
pdDrw
lDGnd
lGSMM
recCB
mtPmj
cuDrw
prepT
drwCB
oPasD
o1Drw
lckDnBf
prpTx
inst
stpSctnTL
o1ShV
scSVI
oPas3
sssmC
sbDrw
aniMt
ppSSSM
drwROM
drwIn
wDraw
lDPGT
oSDrw
oPasO
lDSky
swRdr
ppSWDD
swRdGeom
swRdGeomVB
swFillV
oPasA
ppShrpn
lDWat
oPas2
o2Drw
oPas5
o5Drw
EDraw3D
MEventPrcs
cLGSY
stpAll
stpCB
stpTxtCS
stpUAVsCS
ppHDRCL
ppGSB
ppDOF
ppGlwNw
ppGLu
stpCBUpd
ppQWt
ppCMAA
hudDr
3DEN_UI_OnDraw
3DEN_PrepareDraw
clObL
3DEN_Drawing
stpTxtGS
txt2D
mapDr
mapSeaAndNormal
mapPM
lndPM
MapObjectsPrepTask
mapSeaAndNormalDraw
mapCntDraw
mapObjectsDraw
mapForestShape
mapGrid
drwFn
dtTot
wFram
3dSwp
preLd
preLV
actObjPrld
hashChk
sSim
enfWorkShort
updAttPos
oSo1AN
prpAMCf
prpAMCSlt
prpSDM
locL
mapSeaAndNormalWork
mapObjectsPrepWork
drwIdxPrm
oSo3
lsCVB
oSo5
oSo2CL
oSo1AF
Visualize
visul
txMLo
oSo2Srt
oSoSdw
prpAMCbsi
prpAMCp
Render
bgD3D
stpTxtVS
ppHBAOPlus

private _ctrlTV = ctrlparent (_this select 0) displayCtrl 101; private _export = "{| class=""wikitable sortable""" + endl + "|-" + endl; _export = _export + "! Technical Name !! Descriptive Name !! Description"; private _fnc_logChilden = { params ["_path"]; for "_i" from 0 to ((_ctrlTV tvCount _path) - 1) do { private _text = _ctrlTV tvText (_path + [_i]); _text = _text splitString " " select 0; if !(_text in _export) then { _export = _export + endl + "|-" + endl + "| " + _text + endl + "| " + endl + "| "; }; if (_ctrlTV tvCount (_path + [_i]) > 0 ) then { [_path + [_i]] call _fnc_logChilden; }; }; }; [[]] call _fnc_logChilden; copyToClipboard (_export + endl + "|}" + endl);

See Also

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