#dev_rc_branch
1 messages Β· Page 2 of 1
(Happy to donate anything that people like, btw. Iβm aiming for something more realistic but not everyone may like it)
I will try tomorrow. (Will not get time today, sadly)
Got a bit more time than expected this evening...
So I think this works as we expect but slightly harder to judge in non IR conditions
Top images are x10 brightness to lower images
https://cdn.discordapp.com/attachments/752836925903077418/1063226013598892112/image.png
I've just realised that looking at this kind of thing through NVG (probably with much lower brightness) might be a better indication of success or not. π€¦ββοΈ
This is doing the same test again but viewing the visible laser in darkness through NVGs.
(Obviously with the brightnesses turned down a lot from the earlier image)
https://cdn.discordapp.com/attachments/752836925903077418/1063229328042770512/image.png
Again, the difference between the two images is a factor of 10 on brightness
It's possible that when going up on brightness, we'd want a slightly different texture where the drop off from full saturation to zero is a little tighter but I suspect what we have would be OK.
Although that would rely on there being some control over dot colour/brightness in NVG mode too.
(Oh - and all testing done with 2.12 dev build. Probably obvious that was the case but just to clarify!)
It would be super useful to expose the texture of the dot to mod makers as not all devices project just a simple 'dot'.
hardcoded quite deeply
Understood. Thanks for looking into this though.
SOON (tm)
Could we imagine an Arma screen to be able to display on request a truncated map with markers on objectives?
Somewhat a zoom on a chunk of the map for briefings.
Currently interested in with auto generated missions (Liberation, Hearts and Minds, etc.) As there is not really a true briefing feature.
Imagination has no bounds
In fact, the idea is not so much different from the existing Vanilla GPS, but rendered on a larger screen (BI briefing monitor for example).
Player would be able to scroll and zoom the map on it.
I guess a FOV slider is out of the question?
Personally I'm not against it but it is not up to me to make this decision. make a ticket just in case
Aren't custom FOVs breaking quite a bit of things?
yeah it has issues with several UI related features
it completely breaks https://community.bistudio.com/wiki/ctrlSetAngle for one
Helo
OnScriptError eventhandler
[error text, filename, fileline, fileoffset (character from start), filecontent (the whole function/file as string), stacktrace (literally output of diag_stacktrace)]
? Enough?
addMissionEventHandler ["ScriptError", {copyToClipboard str _this;}];
[] spawn {
sleep 5;
call {
_x = 50/0;
};
};
->
[
"Zero divisor",
"",
7,
128,
"addMissionEventHandler [""ScriptError"", {copyToClipboard str _this;}];
[] spawn {
sleep 5;
call {
_x = 50/0;
};
}",
[
["",6,"",[["_thisscript",<spawn>
sleep 5;
call {
_x = 50/0;
};
],["_this",[]]]],
["",7,"",[["_x",0]]]
]
]
that's great Dedmen! I need to install DEV for this, is there anyplace where I can download the exe only or do install the whole thing?
switching from stable to dev isn't that big of a download I think
and its not there yet
asking for feedback before i finish it
looks good to me Dedmen, can say more once starting to work with it
looks incredibly usefull
is variable values feasible? of the error line (if any), or even some/all in the same scope?
All rights reserved by the respective copyright owners.
http://leroyaumedesombres.tumblr.com
Perhaps limiting the "FOV slider" settings depending on resolution to values where the UI won't look broken? Perhaps stablishing a more modern FOV as the default value and allowing to go +/- 20 on that updated value....
It seems like most veteran arma players always increase the FOV value to at least 80 so that old school tunnel vision is no longer an issue. It modernizes how A3 looks greatly specially when watching YTB videos and comparing to newer games. Anyway I hope these new sliders can be given the uses they deserve. Keep on rocking guys
look at what diag_stacktrace command does
If I make a ticket could you point out the UI related features that have issues and at which FOV values? So that the devs can measure if the FOV slider is feasible. Players are already changing the FOV via config files but that can potentially lead to more issues since it requires external tools to calculate the optimal FOV for each resolution etc etc. Having an official way to do it that in the mean time only allows correct values for any given resolution would reduce the chance of UI getting broken in the first place by those players already modifying their FOVs via the current "hacky" way
you mean like that?
https://feedback.bistudio.com/T136844
https://feedback.bistudio.com/T153943
the second is resolved but i am not even sure if it was ever fixed.
So it seems the issues were already looked by some of the devs and are at least acknowledged. Perhaps the FOV slider is a good enough excuse to bring those tickets to the finish line... It all depends on what the devs a currently working on and their available time I guess
tbh i lost hope on thsoe to be fixed a while ago
i accepted the bean formed radar in peoples videos and the many many people asking why it is broken
BIS_fnc_KK changed Resolution from Open to Won't Fix.
Well yeah, I remember loosing hope on those group event handlers and then we eventually got them so... There is always a chance no matter how small the %... The slider itself is another proof of a feature that many had given up on and it is finally coming π
Ok @wise skiff it is ok if you loose hope again, nevermind my previous post! π (I can eat my own words in peace now)
Just get a 21:9 
ultrawide all the way
I guess I could use the neck exercise! π
What is sad about the FOV situation is that eventually players could have difficulties finding those external FOV calculators currently required for setting your custom FOV properly... so without an official in game way to do it the external way could become one day inviable
even a script command to change the fov would be nice
A script command would pave the way for a config slider anyway. And since the UI issues that custom FOV values cause are minor and players use custom FOVs despite them anyway so even if the UI issues are not fixed the benefit of having a safe way to alter FOV is pretty substantial compared to what we have now
A big turn off for changing the FOV for me was that it does it to third person too.
https://feedback.bistudio.com/T166838
Mh. How did noone notice this yet....
If passive radar sensor detects a active radar. The detection is ignored until the active radar is ALSO in visual range...
Engine ignores all sensor detections, if the target isn't ALSO visible by eye or audible by ear π€
So even though ActiveRadar hits your PassiveRadar through fog, you cannot detect it because there is fog π€―
fog as in the Fog, or draw distance?
both
if not visually visible, sensors are ignored (EXCEPT datalink, that actually has a special case which overwrites visibility to always be visible, so if something is also detected via datalink, all your sensors work)
A radar nyx sends out radar waves in a 16km range.
So passive radar in ~16km distance should detect it.
But in reality (because of the above) its only detected at 7.8km :sad:
(On my current view distance settings)
Actually yes, its view distance dependent. When I up my view distance to 12km, it detects the nyx at about 12.9km (it should be 16)
With my previous settings of 1km view distance, it detected at 7.8km.
So passive radar sensors being view distance dependent will also be fixed by that
Indeed being able to choose a first person FOV and a third person FOV via a in game slider would be optimal for most scenarios
Does DEV always show script errors despite of -showscriptErrors ?
ok, I cant get rid of the black error box, it always shows up
fix it? im on DEV
fix the error
showScriptErrors doesn't work in 3den if that's where you're testing it
Im running mission from eden
same difference
you mean it shouldnt even show the black box?
I mean it always shows the error in 3den regardless of whether you have enabled it or not
ooh that explains it
Introduced to show errors in scripts on-screen. In Eden Editor, script errors are always shown, even when this parameter is not used.
it doesn't have an override option? 
what's the point of making it then?!
i mean maybe we can get disable the black error box option?
well it would make more sense if you could return true in that EH to override it
yes
When i last tested couple of days ago, dev build did indeed show error box even in SP when not asked for 
Does anyone have any more info on this new dev branch feature, and how it can be utilized?
Added: Engine support for weapon optics with an integrated flashlight / laser
Might be about this? #community_wiki message
reminds me of that one terminator sight
I can already imagine the new steam workshop item "fix script errors" π
Is there any reason why when I export a map (as in tactical/strategic map, not terrain) as an .SVG, but convert it to another file format (like .PNG or .JPEG), the roads disappear? How do I prevent that from happening?
(I also hope this is an appropriate/applicable place to ask, since I have to opt into the Dev branch to be able to use the commands.)
sounds like an issue with your conversion from SVG 
OMG thank you! I knew the visual sensors were view distance dependent (in fact i think even objectViewDistance dependent, iirc oukej said that was by design) but I didn't know passiveradar was as well.
(Visual/IR sensors being limited by objectviewdistance is annoying because often objectviewdistance needs to be quite small to remain playable for many people still on older systems. As a result, sometimes a ground vehicle should be visible to the sensor but it's not unless it's actually rendered, even if there is LOS and engine is on etc).
Regarding the original thing we found, I had long known there was something wrong with passiveradar. After Jets launched, maybe even when it was in dev (2017), i thought it was because turrets or AI was turning radar off https://feedback.bistudio.com/T124657 . But then when we found the actual cause i realised it was never about the AI π
You put flashlight/laser config (like you do on side attachments) onto the optic attachment, in the exact same way
No
And it doesn't make sense that radar would be limited by view including fog. Radar just goes through that stuff
how does that radar stuff work with knowsAbout limited by viewdistance? (aka AI forgets about units too far away again)
Slightly annoying
_name = veryLow, _text="low"
Love it
BI be like
there are always known crashes. but they are old
any comment from devs about the black error box, if we can get rid of it?
In Eden? I guess not
In actual mission, it is simply done by untick Show Script Errors
yeah
except on dev it shows in SP anyways :3
but now with the new ScriptError EH it's getting in way
I like the black box. We should make it larger
Would be awesome if we had the option to change where on screen it's displayed
I think I made a ticket a while back about that.
make it full screen. And add WinXP error sound
Right now it's always on top of the debug console
getVideoOptions
[
["aspectRatioName","Auto (Stretch)"],
["brightness",1],
["cloudQualityName","VeryLow"],
["displayModeName","Window"],
["dynLightsCount",4],
["dynLightsQualityName","VeryLow"],
["guiScale",0.55],
["guiScaleName","Small"],
["hdrQuality",16],
["hdrQualityName","Normal"],
["objQualityName","VeryLow"],
["objectVisibility",800],
["overallPresetName","VeryLow"],
["overallVisibility",1000],
["particleQualityName","Low"],
["pipQuality",512],
["pipQualityName","VeryLow"],
["pipVisibility",835],
["ppBloom",0],
["ppBrightness",1],
["ppCausticsQualityName","Disabled"],
["ppColorPresetName","Default"],
["ppContrast",1],
["ppDOF",0],
["ppFSAA",1]
["ppPPAAQualityName","Disabled"],
["ppRadialBlur",0],
["ppRotationBlur",0],
["ppSSAOQualityName","Disabled"],
["ppSaturation",1],
["ppSharpenFilter",0],
["refreshRate",60],
["samplingPercentage",100],
["shadowQualityName","Low"],
["shadowVisibility",100],
["terrainQuality",25],
["terrainQualityName","Low"],
["texQualityName","VeryLow"],
["vsync",false],
["waterReflectionQualityName","Disabled"],
]
Feedback? mainly on names or if something is missing, this is HashMap.
Maybe switch XVisibility to visibilityX
I excluded resolution because getResolution command exists? Is that fine or should it be there anyway?
I'll probably also add some extras that aren't actually in the settings screen (refreshRate already is there)
Could also add some non-option things, like what GPU the user is using? And driver version? Is that useful?
I excluded resolution because getResolution command exists? Is that fine or should it be there anyway?
Maybe to have it all in one command.
Annoying thing with resolution is, its 3 values. width, height, string
I guess I could pack it as array though
Are those pp returns 0-1?
0-2 actually.
The UI display also goes 0-200 (it displays percent?)
Some possible extras
["xDesktopHeight",1440],
["xGPUName","NVIDIA GeForce GTX 1660"],
["xInstalledVram",6270484480],
["xMonitorH",1440],
["xMonitorW",2304],
["xMonitorX",0],
["xMonitorY",0]
["xSharedVram",8523067392],
["xSystemVram",0],
["xTextureMemory",0],
Great, now we can punish ppl for having bad grafix π
While you're interested with video settings, can you give this ticket a favor? 
https://feedback.bistudio.com/T163827
(alternative pp effects)
π First giv feedback on this and get this done
Then push the Dev Branch!!!!!!!!!!!!!!111eleven
If we can get GPU can we also get CPU?
Prooobably, but that doesn't fit in here
easy fix
new command getHardwareInfo
π
Thinking about that. I guess getVideoOptions should indeed only return what's available in A3
There are video options that are available in A3, but just have no UI element to configure them
Anything cool?
there is a refreshRate one π
GIVE
["xStat0","13 MiB"],
["xStat0N","Buffers"],
["xStat1","122 MiB"],
["xStat1N","Textures"],
["xStat2","46 MiB"],
["xStat2N","RenderTargets"]]
["xStat3","2.0 MiB"],
["xStat3N","Other Texs"],
["xStat4","48 MiB"],
["xStat4N","Other"],
["xStat5","231 MiB"],
["xStat5N","Total"],
VRAM Memory usage.
Thats the last potentially useful extras I could find
Oki I think thats my final
[
["GPUName","NVIDIA GeForce GTX 1660"],
["aspectRatioName","Auto (Stretch)"],
["brightness",1],
["cloudQualityName","VeryLow"],
["displayModeName","Window"],
["dynLightsCount",4],
["dynLightsQualityName","VeryLow"],
["guiScale",0.55],
["guiScaleName","Small"],
["hdrQuality",16],
["hdrQualityName","Normal"],
["monitorResolution",[0,0,2304,1440]],
["objQualityName","VeryLow"],
["objectVisibility",800],
["overallPresetName","VeryLow"],
["overallVisibility",1000],
["particleQualityName","Low"],
["pipQuality",512],
["pipQualityName","VeryLow"],
["pipVisibility",835],
["ppBloom",0],
["ppBrightness",1],
["ppCausticsQualityName","Disabled"],
["ppColorPresetName","Default"],
["ppContrast",1],
["ppDOF",0],
["ppFSAA",1]
["ppPPAAQualityName","Disabled"],
["ppRadialBlur",0],
["ppRotationBlur",0],
["ppSSAOQualityName","Disabled"],
["ppSaturation",1],
["ppSharpenFilter",0],
["refreshRate",60],
["samplingPercentage",100],
["shadowQualityName","Low"],
["shadowVisibility",100],
["terrainQuality",25],
["terrainQualityName","Low"],
["texQualityName","VeryLow"],
["vramInfo",["5.8 GiB","7.9 GiB","0 B","231 MiB","5.5 GiB"]],
["vsync",false],
["waterReflectionQualityName","Disabled"],
]
yeah vramInfo and gpuName and monitorResolution are not settings, but it somewhat fits in here and I wouldn't want to make a extra command for such.
Will probably document that vramInfo/monitorResolution are optionals that are not guaranteed to be there. So we can remove it IF we add some hardware info command (which I don't think we will)
Why would mod makers actually want to access that? Because the first thing that I can think of is game client fingerprinting (which is not a good thing)
Vram is useful to detect 3fps bug like problems in script.
monitor 
If you want fingerprinting you can grab steamId, or store value into profileNamespace
Should those optional elements be moved to the end of the output array, so [properly configured] params on the output don't get broken if they're removed?
its not an array, its a hashmap
Oh, okay
I meant correlating data for people who play using different SteamIds
Yeah. For people who move between steam accounts and also change their profile and their game window resolution everytime they connect
Then you also have audio volume settings.
Which in basically every case is a malicious actor
There are already enough ways to do fingerprinting if someone wanted to
Which in basically every case is a malicious actor
Well, I understand your argument and also understand that there are other ways of fingerprinting.
Just wanted to point out that this makes fingerprinting ever easier (or harder to work around). And while I also understand the part about being a "malicious actor" most of the time, it kinda sounds like a "if you have nothing to hide then you shouldn't be concerned" which always surfaces while talking about privacy.
And as a side note and more of a fun fact: the Wasteland server that I've been playing on actually had whole groups of people (at least one that I know of) that were actively switching both player profiles and steam accounts to go undercover so that others don't know who they are facing and what are their usual tactics. They stopped doing that only when officially asked by admins, after numerous complaints from the community. [no, it wasn't me]
No FOV stuff?
Oh my god, yes pleasseeeee DOF would be beyond incredible
Can we check this wasn't turned down since a3 launched π₯Ή
I know it's not a video thing, but would be cool if we could get ram usage as well.
Especially for server/headless clients. Currently it's only possible for servers via #monitor.
The "Name" values - are these internal names, or localized? π
Gamma is missing. Which btw is weird when you screenshot/print screen, doesn't affect the result.
all nonlocalized
its.. not.. I know I did it
mh its missing. Probably a copy paste error π Thank you good eyes
Gamma was the main thing they wanted and I didn't see its missing π
yw π
Is it an array of arrays or a hashmap?
hashmap
yeah i was thinking of this as well, RAM and heck pagefile even if the application tracks that
my client crashes whenever i join server
Build: Development
Version: 2.11.150223```
okay narrowing it down
@full sonnet @unreal arrow game crash addUserActionEventHandler ['turbo','activate',{}];
@unreal arrow "windyCoef" appears to either not work, or be slaved to "ambientSound" toggle
top of tanoa volcano, enableEnvironment [FALSE,TRUE,0];
gimmie repro because idunno what u mean
just join as client in mp and exec
yet π
what version
@unreal arrow Version: 2.11.150223
i tested with dedicated server, not MP From editor
there is missing windy input from one of the wind sound shaders
manage to repro the user action issue?
heh, good job
Lazymen
Result: 0.0013 ms
Code: true;true;true;true;true;true;true;true;
Result: 0.0016 ms
Code: var;var;var;var;var;var;var;var;
->
Result: 0.0009 ms
Code: true;true;true;true;true;true;true;true;
Result: 0.0011 ms
Code: var;var;var;var;var;var;var;var;
The world is saved! π©
Result: 0.0007 ms
Code: true;true;true;true;true;true;true;true;
poggers
Optimized semicolon? 
split nular commands and variables into separate instructions
Working on old ticket by this weird guy https://feedback.bistudio.com/T123419
ah its set to private, sad
Restricted, yea.
Some ticket from some dedmen some 6 years ago
Huh, strange name
so do we get the ability to disable the black error box, now that we have ScriptError EH?
no
Sorry for the ping but is this pushed into Dev-Branch already?
Oh, was me did wrong
Does it show on stable?
I think its good that errors are forced to show for all
designers may feel compelled to fix their stuff
but options aren't a bad thing
repositioning would be quite handy tho as the current position is far from ideal
You mean options to disable on dev branch? for what purpose?
and yes sometimes options are a bad thing
import RscPicture;
class test
{
movingEnable = 0;
idd = -1;
class controlsBackground
{
class text1: RscPicture
{
x = 0;
y = 0;
w = pixelW*512;
h = pixelH*512;
text = #(rgb,512,512,3)text(0,0,"Caveat",0.3,"#0000ff7f","#ff0000","Hallo\n"Welt"");
};
};
};``` @full sonnet sorry for the ping again - do you know why it forces it to be lowercased?
Huh...
It was a thing that all proc texture things are forced lowercase, but that shouldn't be the case anymore
Pun detected
Ill check that
Thanks
Mh, actually i only tested script. Probably smth on the config reading side
Oh and also, this does seem to be happened only in dialogs
Either ctrlSetText or text = attribute, both does lowercased text, but setObjectTexture'd object has proper text
didn't understand the question π
yep. The control itself has a forced lowercase
so.. previously it would lowercase each texture path twice... :yay:
I think he means the forced one inside eden editor and preview
fixi
oh, i tested with Prof (without script errors on) and it does show small error box
in the editor (launched) that is (error from console)
ye inside editor errors are forced on
something I already knew..
Display and texture both uses same texture and almost the same script I've ran, but texture doesn't do what I want - which is to sort the width with the text width using ctrlTextWidth, bug?
Wait, I've just realized... somehow the text size is different. Maybe I ain't sure how to control it
maybe your script needs to run in context of the render, aka inside onDraw event
while the thingy is drawn, the engine's screen size and some other stuff changes.
After drawing it changes back
Maybe the textWidth script command output depends on that
Ah hmm, onLoad'ing did fixed it?
Yeah try to change things in onLoad does fix it, but it is hard to try
isnt there some draw or simulate event or smth
Thought map ctrl only has the onDraw?
That indeed seems to be the case
I guess I forgot that
I'll add it then
Done, with a bit of luck that makes it into tomorrow's dev
So both control and display will receive it?
only display
I thought of this problem before and I was sure I had implemented a solution.
Either i forgot to implement it or I forgot what the solution was
Ahhhh there is no display onDraw 
I hate all of this. I guess I'll add a display onDraw event, that only works with UIOnTexture displays
Do wiki please, one parameter, the display. onDraw. Only on as above
Done, feel free to correct
π
When I'm in the Dev branch and I start up the arma3diag .exe, SOG: Prairie Fire isn't showing up in the addons menu, yet all other CDLC is. How do I fix this?
Any idea what causes this? I'm trying to use the SVG export command to make an image copy of the strategic map of Cam Lao Nam, but it doesn't work and gives me an error message that makes no sense. It worked for a map from a mod; I don't understand why the command is having issues with this map.
Did you paste code in from elsewhere?
A lot of those are caused by hidden characters.
You're not running the dev exe
oh yeah :P
dev branch version should be 2.11
The problem is when I tried running the dev .exe, it didn't give me any options to enable SOG: Prairie Fire.
@halcyon moth I copied the example text from the BIS wiki and changed it slightly (as in the name of the saved file, where I want to save it, my username, etc. - I'm good with formatting).
Just now, I also tried manually typing out the whole code, but it gave me the error message again.
It will always give you that error because the command flat-out does not work unless you're on dev branch with the diagnostics exe. It does not exist on stable branch.
So if that's the case, then how do I activate SOG Prairie Fire with the diagnostics .exe?
You're putting vn in the mod line when you start the diagnostics exe?
Nope, though interestingly, when I launched the diagnostics .exe, this time it actually loaded SPF by itself.
I don't know what changed about it, but it works now.
On the subject of the SVG export command, however, is there any way to export it in a lower resolution or convert it to something smaller?
When I exported Cam Lao Nam, it's almost 90 MB.
Itβs vector graphics, it does not have a fixed resolution
Disable trees or other features to get smaller files
About the UIOnTexture crashing on diag binary, thats replaced by skippable assert with todays(maybe) dev update
now is happi time
though it might still be a bit annoying that you have to go through draw handler but welp
If there is still something wrong with anything now on dev, pong me
Does the new change mean we have to use onLoad or can we still use the direct method without onLoad just without the added benefits?
you dont need onload anymore
Okay my dream's done
Is it correct to describe onDraw will fire upon a displayUpdate?
Huh, is TreeFilterUpdated implemented? Can't get it working
class CreateObjectWEST: ctrlTree
{
onTreeFilterUpdated = "_this call bra_fnc_bra;";
};```correct?
yes
UIOnTexture is only drawn when requested
I only tested it scripted :x
I assumed config would just work :u maybe it doesn't
nono it does, the config loading code is definitely there
"onTreeFilterUpdated"
Hmm, it is for a tree not an edit right?
Did you do this with just lightpoint creation? It looks sick
in case you guys didn't know yet you can crash arma if you have script error inside of "ScriptError" EH
:poutcat:
I knew I forgot something
Fixed, the second ScriptError will fire but then no more
Thanku 
and reset after that? for another two?
max 2 level recursion
Just realized that TreeFilterUpdated does work properly, but not for Eden Editor's right hand tree view
findDisplay 313 displayCtrl 56 ctrlAddEventHandler ["TreeFilterUpdated",{systemChat str _this}]```Repro
No wait, just realized that the Eden tree doesn't use idcSearch 
How come I've never noticed this
Eden editor has a custom tree thingy
its not just a normal tree view.
i think it also has custom search
For the love of god dont touch it
weird effect where screen layer disappears when aim down sight
is this intended?
example (['TAG_my_layer'] call (missionNamespace getVariable 'BIS_fnc_rscLayer')) cutRsc ['RscCBRN_APR','PLAIN'];
aim down sight and it disappears
Can't repro on internal π€
Definitely not intended. If this is issue in RC then it'll be top priority
hmm ill see if i can repro it
@full sonnet false alarm, i did not realize cameraView changes to "GUNNER" on ADS
my script checks "INTERNAL","EXTERNAL"
so release is even numbers and dev are odd numbers?
Even versions are for main / default branch, odd are for Dev-Branch. It's because they are not and should not be multiplayer-compatible.
https://community.bistudio.com/wiki/enableAudioFeature
possible to enable "building_interior" on an object placed in a building
so it is not a bug if
myHouse enableAudioFeature ["building_interior", false];
does not work on the house (where "building_interior" is true by default), not on the object in it, correct?
no you can only enable it if not enabled, cannot disable it if enabled
why would you need to disable it, is there any legitimate reason?
To fix bugged scaffolding on mission, its open object but have interrior sfx
could you give me the class i would check
there is a ft ticket
https://feedback.bistudio.com/T164238
class Land_Scaffolding_F
ooh if we're doing sound fixes then the 2-floor bunker also suffers from issues like that https://feedback.bistudio.com/T122026
this is from 2016, i confirmed it was still an issue a year or two ago
Land_BagBunker_Tower_F
(i can't check again because no gaming PC)
@light lintel bunker enableaudiofeature ["building_exterior", true] works
thanks, is that true on both floors? as per my bug report
The Bunker (Tower) (Land_BagBunker_Tower_F) uses an indoor audio environment on the top floor, but an outdoor environment on the ground floor.
It seems like the environment is determined by what surface you're standing on. That type of bunker doesn't have a floor surface on the lower level, so it may not be practical to do anything about that.
ah, unfortunate
like the fix would be to make it exterior audio on the top floor as well...
but how come it works correctly on the cargo towers? does the roof have a different surface from the interior?
https://feedback.bistudio.com/T169652 (see comments)
Presumably yes, the model is set up to use an interior surface on the interior and an exterior surface on the exterior.
Oh, i understand what KK said now i guess. That
bunker enableaudiofeature ["building_exterior", true]
would make it sound like the exterior everywhere in/on the bunker?
Fixing the bunker properly would require model editing which at this point may be a bit problematic, so you can use enableaudiofeature as workaround
how about exec the "fix" on bunker and scaffolding configs to make this objects "fixed" by default?
class EventHandlers
{
init="(_this # 0) enableAudioFeature ['building_exterior', true];";
};
Yeah, not the worst idea, I will make a ticket
need to remoteExec if run it from the config?
class EventHandlers
{
init="'the answer is no'"
};
Config runs everywhere where the mod is loaded, so no
Are you guys working on a system allowing to "write" directly on objects like planes, helicopters, buildings instead of having to create multiple textures?
As a reference, the high watchtower numbered from 1 to 8. It has 8 textures.
As an example, creating a grey texture for an helicopter and labelling it with "Navy" in various locations instead of creating 2 textures for the same goal (a standard one and a specific one).
Asking for a friend
definitely not. Delete before it gets picked up
No
Well with UIOnTexture you can probably do what you want
But "we" are not building such a system
Thank you.
Update 2.12 has started its Release Candidate branch testing: https://twitter.com/ArmaPlatform/status/1622978748994801670 
We're kicking off #Arma3's 10th year with a Release Candidate branch for update 2.12. It contains several useful and fun new toys for modders, like new options when using procedural textures.
π‘Details: https://t.co/UzuMegxY5o
π₯Steam access code: Arma3Update212RC
That new update image/thumbnail thing looks really great. much more informative than the previous ones
Does 2.12 include a volume slider for playSoundUI or what was again the plan to deal with it?
Yes, but I don't like it π
So far it's a slider purely for playSoundUI, so some tiny sub-set of SFX and hard to explain to regular users. We are considering to loop most actual UI SFX through this channel in 2.14, but it requires feasibility study first. If that works, it can just become a UI volume slider.
thanks a lot for the info πββοΈ
we are using playSoundUI for conversations atm
this is as usually people mute radio channel when they dislike the radio protocol
the other option is the regular sound channel (fadeSound, soundVolume) - however you want to decouple those from conversations due
- people may want to mute conversations
- you can make conversations louder to the regular sounds (aka easier to understand conversations in otherwise loud environment)
finally playSoundUI also works outside missions (ie main menu without a cutscene running, briefing or debriefing) - this adds a lot of new opportunity and flexibility
I hope that helis not force-exploding anymore when falling on the side is also part of 2.12, because it's been a very long time in perf branch. even before 2.10 @full sonnet
its not
why?
because it wasn't enabled
For the record, I didn't have any issues on perf branch that could be tied to that fix, so it looks like it doesn't have side effects (at least in my use-cases)
it is, in perf.
if no further/additional tweaking is expected to this, why not make it as default in stable?
Because noone thought of it
well. same for patch 2.10, although it's part of perf branch even since before stable 2.10
hope it will come in patch 2.14
@past moon is there something wrong with arma3diag.exe at the moment?
I just updated Dev Branch, using GameUpdater, and cannot run the Diag exe, re-validated and downloaded the binaries, tried with no params and still
What does platform support supposed to mean?
In what sense?
In the twitter picture it just says that. But I have no idea what it means.
and/or occasional bugfixes
Platform support is the continued maintenance and development of the technical platform - enginestuff, scriptstuff - that content is built on. It means "code updates but no new content".
For people who've tried the new setTurretLimits command, when the gun is outside the new limits when they get set, does it smoothly traverse to the new limits, or instantly snap there?
iirc it snaps
ye instantly to new limits
yeh
I can make it zero if limits change if you have concerns someone may exploit it
@steep monolith Nothing is wrong, an ASSERT is not an error. In brief, it's a debug message to inform on a value or something. Is it possible to have your log? (will try to have a look)
Q about that. are the limits player only or apply to AI as well
AI as well as far as I tested
No, I was just curious for aesthetic reasons, whether it was smooth or instant. I don't think it's especially exploitable, certainly no more than lockCameraTo.
[still hoping to one day get "lock in current position" :D ]
the command purpose is to set static limits on static weapon so that it wonβt clip near objects, so technically you would set it once after you placed your assets
That's definitely the most important use for it.
Personally though, I'm going to use it to restrict the turret traverse on certain vehicles that have exterior infantry seats, so you can't turn the turret backwards while there's infantry sitting behind it. (I also want to do travel locks, but you can't set negative angles, so the gun could only be locked forward, not backward.)
To be clear I was just asking for information, not complaining. If you want to do something cool like an optional bool for smooth/instant, I'm not gonna say no, but it's not strictly necessary for my purpose so I'm not here to pester you about it.
no, animation requires new implementation, so unlikely
not sure how feasable but you could adjust the gun limits from a to b over 1 second to fake the affect of a slower transition?
new RC out?
13-02-2023 (notable changes)
Fixed: Crash if a script error occurs in a config file at game start - FT-T170230
I've recently been experimenting with the new UIonTexture procedural, but I'm finding that when applying the display to my weapon I can't manage to get the alpha to work. Anyone know how to get the controls to display with transparency?
I've also been getting error messages upon loading my weapon with the display that state, "Cannot load mipmap file\path\here.paa"
This appears to be the same problem TeTeT was having, but when I asked them, they'd not found a workaround.
#arma3_texture message
transparency also depends on the model, if the faces on the model didn't have transparency when it was binarized, it won't have any transparency even if you put a different texture on it
Thanks for your response. How would you recommend I add transparency to the faces? I've tried a few things along that line, including using "ca" at the end of the procedural and using argb, but that didn't appear to fix my problem.
I am going to try to set it up where the texture in the p3d is an image with transparency and apply the UIonTexture via hiddenSelections, but if there was some way to tell the model from the p3d that the UIonTexture procedural should consider transparency, that could be useful.
This did work!
It needs to have a texture with transparency on it, when you binarize the p3d
A simple procedural should work too
@steep monolith Aye, mine be working. Sorry just now had time to check it.
http://hastebin.com/owaxeduqiw.tex im pretty sure im just going to delete it all and start again copying the latest stable into its place to begin with
gah, that is sub optimal for sure.
Would it be possible to add a missionEventhandler for "TicketsDepleted" as an alternative to having to end the mission via template?
its a scripted system. so you need to make a scripted eventhandler with the right logic
"respawnTicketsExhausted" https://community.bistudio.com/wiki/Arma_3:_Scripted_Event_Handlers this?
Yes, I can not remove the scripted event
When I try to remove the scripted event that you typed it does nothing
are you sure you remove it correctly?
do you remove all of them or do you know the ID?
[missionNamespace, "respawnTicketsExhausted"] call BIS_fnc_removeAllScriptedEventHandlers;
Called it on the server and on every machine - Nothin changed, still ended mission at 0 Tickets
looks like it just triggers the event
you can't actually do anything with it
and you said you wanted to end it a different way not keep it going forever 
well then why do you want to remove it?
just end the mission yourself using that event
in other words add an EH not remove the EH (plus there was nothing to remove anyway)
Will it overwrite that event?
no. you just end it sooner before it ends the mission itself
I just want the mission to end when there is no respawn tickets, there is still a possibility to get tickets in the mission im building, so I want players to be forced to spectate until a ticket was scored
"do not want"
But anyway, I accepted it, it will also work this way. I just track in the script that is called on mission ending if there was no tickets left.
I just want the mission to end when there is no respawn tickets
well just put:
[missionNamespace, "respawnTicketsExhausted", {
["end1"] call BIS_fnc_endMission
}] call BIS_fnc_addScriptedEventHandler;
in init.sqf
Typo: I meant I want it NOT to end ^^
But I will accept the verdict.
@dusty scarab you can also duplicate the relevant scripts of the respawn system, modify them to your needs
You are right. Well, I go with the flow - I end the mission on 0 Tickets.
Whats coming up for 3.15?
Given that the current stable version is 2.10, it's a little early to be looking as far forward as 3.15
I'm trying to use UItoTexture for an ammocounter on a weapon similar to how Polpox had shown earlier in this channel, but I've found that the functionality is fairly limited from the sense that all weapons of this particular type would share the same unique ID. Is there any possible chance that we could get a setting for the UItoTexture procedural that randomizes the unique ID on the display's initialization?
I would think that you only see it from First Person Perspective, so did not make any randomization or such
But had to admit such limitation is not good since how a weapon behaves
I meant 2.15
We really don't know that either. The next update, which is currently on release candidate branch, is 2.12. After that (probably in about 6 months) will be 2.14. 2.15 will be the dev branch for stable update 2.16, and since that's like a year from now we have no idea what's going to be in it.
Perhaps it will be a 10-year Update π
i will personally be releasing 3.15
To add even more to this, the feature would be extremely useful for workarounds in regards to scripted texture application to vests, headgear, nightvision, you name it. The main thing is that this would be especially useful for objects that cannot have a scripted use case for UItoTexture where instead of application via setObjectTexture, you are forced to use hiddenSelections or application of the texture through the p3d.
Nice 
Very good news. Thank you!
are the rc branch passwords randomized or something known?
im asking what's the password of the rc steam branch
where is it posted?
rc branch for what 2.12 is out
says dev hub but im not seeing anything related to RC
yeah i know, its late now
but im curious anyways
was there a rc anyway or not?
yes
does the password follow a pattern like the other branches?
Arma3Update212RC
why its not mentioned as such on wiki :/
Because noone wrote it there yet π
ohhh
how do i make use of game updater?
there's a wiki page for a description of the application but there isn't a tutorial or something i can see
The RC branch code is also included in the announcements when the RC branch is launched, for example https://forums.bohemia.net/forums/topic/183855-release-candidate-branch-announcements/?page=2&tab=comments#comment-3471642
thanks!
Actually, i think not.
Each player generates the procedural tex locally.
How to network sync the random unique name, on something that isn't network synced...
So well yes i can make it random, but it wouldn't be same random value per weapon in MP. Which is what you'd actually want...
What you'd need is a way to get the parent entity.
Had that idea before but oof. And especially when texture is reused in different places it becomes impossible (unless array of parents)
Just to have all info in one, we share intel about RC tests via:
- Twitter: https://twitter.com/ArmaPlatform/status/1622978748994801670
- Dev Hub: https://dev.arma3.com/rc-branch
- Forums: https://forums.bohemia.net/forums/topic/183855-release-candidate-branch-announcements/
But the 2.12 RC was closed yesterday, since the update was released to main branch. The next RC branch typically arrives a few weeks before the next update (2.14). ETA: late summer 2023
So is there any hope to get the number of available custom chat channels dramatically increased? Like from 10 to 100 or something like that. There was chat about it on scripting channel already, but just posting it here as well just in case because I feel it would be an important upgrade. The current number of channels is understandable due to it being apparently hardcoded pretty well, but if the workload to change it is not extreme, I think many of the community devs would appreciate increasing the number drastically a lot. Requesting this explicitly here because the concept of customizable chat channels itself has so much potential but the implementation breaks it with such a low number of channels. Gib plz

you have a link to the discussion?
Dedmens answer: #arma3_scripting message
is there a ft ticket I can have a look if there is a less painful way to up it
Don't think so, but that can be arranged I'm sure π€
Actually there is a pretty old one, but same question and same answer from dedmen: https://feedback.bistudio.com/T159403
If you manage to do it, please use an actually high enough max value (I think 100 would be the minimum here, even 200 would be neat). It would allow so many great things π
Thanks for looking into it in any case!
2021 though, some code have changed since
200 no 101 maybe
Will https://community.bistudio.com/wiki/addWeaponWithAttachmentsCargoGlobal get the same treatment as other commands such as https://community.bistudio.com/wiki/addWeaponCargoGlobal, where you can use a negative number to remove weapons?
never got findDisplay "dispNameHere" working. my display is defined in description.ext
only works for UIOnTexture
Just to clarify at the moment, you can only have a single UI on texture on a spawned weapon/scope per MP server right?
Like due to the unique name/number at spawn
oh that explains it. not sure if that is mentioned somewhere in the wiki
no, one per texture
Noticed recent bug, in zeus, place a group and click-drag over them to select the lot of them, the audio bugs out at everone of them doesn't stop talking until you quit.
Anyone able to confirm this? I'll then hit up a tracker issue
Is FSR for Arma 3 dreaming too much?
Thereβs https://store.steampowered.com/app/993090/Lossless_Scaling/ as well as many other to enable FSR or NIS for any game
Lossless Scaling lets you upscale windowed games to full screen using state-of-the-art spatial scaling algorithms, sharpening algorithms and machine learning.Scaling algorithms are currently presented: LS1 AMD FidelityFX Super Resolution (AMD FSR) NVIDIA Image Scaling (NIS) Integer Scaling Nearest Neighbor xBR Anime4K Sharp Bilinear Bicubic CASL...
$4.99
1025
Donβt see why youβd need that since arma 3 is incredibly CPU bound, not GPU
just to help the people suffering from GPU bottleneck
Anybody with a GPU made within the last 7 years (or even an integrated GPU made in the last ~4 years) should be able to run Arma 3 with no issues
@steady sundial wait till Thursday DEV build, if it still keeps doing hit the tracker
No, but also yes because of what FrozenDroid said
I max out my gpu usage on a3 π€·
Which GPU? What resolution?
Is it possible that the GPU is down clocking itself to save power, and as a result showing higher GPU utilisation?
I know it can become GPU bottlenecked on certain CUP maps and Tanoa when using 8x SSAA even at 1080p
1050 ti at 1080p
if it was down clocking itself i wouldnt expect its temp to get into late 90s
I'm curious to see what people think about the fatigue/stamina changes.
I mean people here, but yeah I've seen that
I tend to agree. I wish they wouldn't step away from a system that could have used some refinement but was generally good as it was
But I'm curious to see if people have more suggestions as to how to make the new system better.
@wise dragon modern cards can down clock to lower power consumption independent of temperature (so do verify clocks), but yeah a 1050 Ti is more likely to get GPU bottlenecked
rgr -- check clocks just via task manager?
Why don't you use the overlay that comes with Nvidia experience? I seem to remember it shows enough information (and will be more accurate than task manager)
theres one with nvidia experience? 
Yes open the nvidia overlay while in game and press performance, the settings are in there.
dosnt show memory utilization though.
Bruh moment ill look later
Just remember to set your performance HUD settings to advanced to see more stats
There's also stuff like HWiNFO and Riva Tuner Statistics Server if you (like me) don't use GeForce Experience
i was happy with the system as it is. staminabar is a nice extension to the hud, tho
Can we have an option to not log the Server: Network message XXXXXX is pending T_YYY logs on the server RPT like we have for Server: Object X:YYYY not found (message Type_ZZZ) logs with the LogObjectNotFound=false setting?
yay for mipmaps, boo for non-zero mipmaps being empty 
Closer π€
@trim crane I hope you'll be happy with this π
In the uiEx variant I could let you specify https://learn.microsoft.com/en-us/windows/win32/api/d3d11/ne-d3d11-d3d11_filter, but default just D3D11_FILTER_MIN_MAG_LINEAR_MIP_POINT
Calculating mipmaps will increase the rendering cost a bit-ish, so will probably recommend on wiki to only set 1 mip, unless you need more
Theoretically possible to render different UI for different levels lol. But probably better to leave that stone burried
I mean... Its quite simple to do, for uiEx that could be an option. But it will be much more expensive. It has to process all mips at once even if it doesn't currently need them
Its... BEAUTIFUL!
only mip0,
0->1->2->3->4->...
0->1 0->2 0->3 0->4 ...
π€
Maybe you can choose another scaling function? (can you even?)
I can ye
Lanczos was quite good at scaling, AFAIR, but there were sinuses involved, so I guess that's not optimal for something like game π
Well I can choose the ones DirectX11 offers me
I don't really want to write a new scaling shader
What is it that's currently being used, out of curiosity?
bottom row D3D11_FILTER_MIN_MAG_LINEAR_MIP_POINT, top D3D11_FILTER_MIN_MAG_MIP_POINT
I could do MSAA too but ugh no
Now just gotta fix game crashing when you hide the Eden UI 
I wonder how it would look with D3D11_FILTER_ANISOTROPIC π€
Ignore right column.
D3D11_FILTER_ANISOTROPIC
vs D3D11_FILTER_MIN_MAG_MIP_POINT
looks basically same as D3D11_FILTER_MIN_MAG_LINEAR_MIP_POINT looked in that its just darker
mh okey a bit smootherish
I guess it could make an impact if you're looking at it at an angle
I wonder what would be closest look to original texture handling
Can make you a repro that ui2displays all vehicle textures and sets them on a vehicle next to a normal textures
That's what I plan to do in the game, procedurally ui2display modify existing vehicle textures or create new ones
Normal vs Crispy
Aniso Filtering: Ultra va Disabled vs Crispy
Fixed: Changes of slider Control positions caused by the engine or scripting did not trigger the "SliderPosChanged" Event Handler
Was even an issue?!
There aren't many places where engine updates slider position
mainly everywhere where you have text boxes that also update the slider
I guess that fixes the Eden issue where edit boxes stayed empty?
that was caused by that yea, but thats #perf_prof_branch, dev branch has that thing and the fix for it. prof is missing the fix for it
UIonTexture mod showcase or something:
https://youtu.be/yaX2qWnm7s8
mandatory plug for sensitivity control
https://feedback.bistudio.com/T168865
In audio settings all sound previews (effects, radio and music) are start playing automatically
in new Dev and Prof
Cool stuff!
Thought about how great it would be for PIP scopes and there it is
Thank you π«‘ We'll revert that change
Do I have to pay to play my own missions now? 
Yes of course!!!!11
Run Steam 
Game HAS to verify I paid for the custom mission or it won't run
I had it on, just borked build it seems
2.13.150442
We didn't make changes to that code (but some non-code changes that.. shouldn't cause this π€ )
Did you try steam verify and full pc restart?
Nope, just reverted to stable for now
Can try it again
Did you try Dev branch before yesterday?
Version: 2.13.150408
been on this build for like a week or two
That one did not have the issue?
Nope, it was fine
Updated, then no longer was able to run any missions, also none of DLCs or mods were shown in the main menu
16:28:18 SteamAPI initialization failed. Steam features won't be accessible!
```first RPT line
Steam was running fine, restarted the game few times including disabling all mods, had same picture
Redownloading dev branch again, gonna see if it happens after reboot
bad steam dll?
At this point this is likely my connection issues
Did you try a PC restart yet?
Going to soon
steam is down for me
https://steamstat.us/ still shows all is good
Displays status of Steam client, Steam store, Steam community, Dota 2, TF2 and Counter-Strike
Restarting Steam was enough. It was totally on, everything working but Arma refused to work for some reason π€
Didn't check if stable was affected too or not, so its likely not an issue of dev branch but my local connection\steam issue
Had it working fine just few hours ago, then went to update and it didn't anymore, restarting the Steam helped
Sorry for false alarm
bottom of steam window usually says "NO CONNECTION" when this happens
one of the causes can be creating another session with same id, for example when running steamcmd
Yeah, I checked Steam specifically and it was fine, friends list was there too
That's how you want it right?
or with offset's/viewport changes
Also a thing
#(rgb,2048,4096,8)ui("RscDisplayFieldManual","uniqueName")
#(rgb,2048,2048,8)ui("RscDisplayFieldManual","uniqueName")
Will render two different display instances, even though they have same uniqueName, because they are different "texture sources" due to the different resolution.
I'm thinking about changing it such that only display class and uniqueName are combined to specify the instance, and that multiple textures can share the same display.
if I do that, the above will render the display twice on every change, into the two textures. But there is only one instance of the display in scripting.
I think I'll not worry about backwards compat on that, the feature is new enough that people probably aren't doing that. And.. unique name is supposed to be unique anyway. If it breaks your code that you expect two textures with same uniqueName to be different then.. well bad luck.
This can then be combined with the cropping settings, and the changed viewport, maybe different background color
He be so focused in his work that he doesn't realize I'm talking to him πΏ I don't wanna ping :u ping is annoy
I'm fine with being pinged
This looks exactly how I imagined it
As for as different display instances go, not an issue for me either, just have a note to differentiate with different unique names for different resolutions or setups
I am already using same display config to create different displays for different objects
Maybe store texture name in the display along with its unique name?
STRING = displayTextureSource DISPLAY
Gonna return #(rgb,2048,2048,8)ui("RscDisplayFieldManual","uniqueName")
Though not really needed, if you know what you're doing its not an issue at all
Well that won't work if multiple texture sources can refer to same display
Didn't you mean that having different resolution but same unique name will make a new display?
How do you even have ui2texture refer same display? π€
Currently its that way.
I want to change it so that its not that anymore
I'll be fine with the change as well
Example above, under last image.
Same display class, same unique name, just different resolution.
Should just spawn one display instance and render it twice, instead of spawning two instances
also findDisplay only finds the first instance, if you have multiple with same name
Yeah, I get what you want to implement. I'd be fine with this as well, re-using same display for different textures sounds like a potentially useful feature
Say somebody makes some cool billboard with a display, they'll want to have it with different resolutions when displayed on a huge billboard or a small info stand somewhere
Cool animated billboard even, processing one display and then rendering it to different textures sounds more proper than having to same operations with copies of the display
(That somebody might be me, I want to display scoreboard on some objects at base in game)
Yeah. And also for last screenshot.
The one on the right is same display, but split into two halves. That surely can be useful for smth too
Example syntax for that
#(rgb,2048,4096,8)uiEx(display:"RscDisplayFieldManual", uniqueName:"testName", viewportX:-0.5, viewportH:0.5)
You can display different parts of display, even zoom in, different resolutions, different background colors. But all have it be the same display that you only need to update once in script, and they will all be in sync
Hmm, if there was scaling then we wouldn't need any of these fit or cut options
Fit or cut exactly like you want it
Thats what I'll do with the viewport
The fit version shown above is viewportH:0.5 (only render half height), the second is viewportW:2 (render double width, excess will be cut off)
If its non-1:1 texture, just scale it by width or height (or shrink) and cut off as you need with offset
Yup, I get your idea, that would be even more flexible
Mh..
for uiEx
Do I do for test " test
uniqueName: "test "" test"
or
uniqueName: "test \" test"
I guess the "" is more in line with rest of Arma, but I hate it
omg
No I just realized I won't allow it at all :harold:
You gotta live with no quotes in your uniqueName π
I see no problem with that
ah background color isn't even a thing.
What else could be a parameter next to the viewport stuff
Could make a flag to bypass the same name == same display, and crate new display regardless if it already exists with same name. But I don't like people doing that so won't until I get a good usecase that needs it.
Ah the filtering type for mipmaps!
If they want a new display, they'll make a new unique name
Name already gives you all the options you might want for using same or a new display
Also.. I now have code to render any post-processing effect over top of UI π€
But thats an idea thats probably also better left burried in its grave
when it rains, or force aircraft de-ice xD
For like in-vehicle displays, having like ChromAberration ontop of your UI to make it look brokey-ish, or put blur or filmgrain on it
Actually, this can be useful for PIP scopes π€
Though r2t already have something like that?
Yeah I think it does
And proper error messages 
#(rgb,2048,4096,8)uiEx(display:"RscDisplayFieldManual, uniqueName:"testName", viewportX:-0.5, viewportH:0.5)
-> uiEx procedural texture syntax error: 'Unexpected character, should be ',' or end' at -> 'testName", viewportX'
#(rgb,2048,4096,8)uiEx(displaiy:"RscDisplayFieldManual")
-> uiEx procedural texture syntax error: 'Unknown property' at -> 'displaiy:"RscDisplay'
#(rgb,2048,4096,8)uiEx(display"RscDisplayFieldManual")
-> uiEx procedural texture syntax error: 'Invalid character after property name' at -> ', uniqueName:"testNa'
#(rgb,2048,4096,8)uiEx(display:"RscDisplayFieldManual)
-> uiEx procedural texture syntax error: 'String missing closing quotation mark' at -> '"RscDisplayFieldManu'
#(rgb,2048,4096,8)uiEx(display:, uniqueName : "testo")
-> uiEx procedural texture syntax error: 'Property has no value' at -> ', uniqueName : "test'
Also if you need quotes in string, you can like
#(rgb,2048,4096,8)uiEx(uniqueName : 'testo " test ')
Nice!
display: string
uniqueName: string
viewportX: number
viewportY: number
viewportW: number
viewportH: number
texType: string
quotes are optional so texType:co is possible
Still need to add that mipmap filter type. Anything else?
I guess that's it
Did you try my repro with the vehicles, how did mipmap options compared to stock Arma filtering and mipmapping?
nu, you can try that yourself when I'm done
Mh viewport in pixels, or percent? π€
#(rgb,2048,4096,1)uiEx(display:"RscDisplayFieldManual", uniqueName:"testName", viewportW:2)
#(rgb,2048,4096,1)uiEx(display:"RscDisplayFieldManual", uniqueName:"testName", viewportH:0.5)
#(rgb,2048,4096,1)uiEx(display:"RscDisplayFieldManual", uniqueName:"testName", viewportX:-1024, viewportW:2)
Weird mix out of pixels and percent now.
I think percent is probably easier to use
π€£
Virtual multi-monitor bezels Dx
Its basically UV mapping by hand XD
You could have many different displays handled by making one huge UI, but with different zones on it. I'm not sure if rendering is efficient... Optimally it would not try to render stuff thats offscreen but not sure if that can be trusted
#(rgb,2048,4096,1)uiEx(display:"RscDisplayFieldManual", uniqueName:"testName", viewportX:-0.5, viewportW:2, bgColor:#ff000000)
#(rgb,2048,4096,1)uiEx(display:"RscDisplayFieldManual", uniqueName:"testName", viewportX:-0.5, viewportW:2, bgColor:#00ff0080)
Setting background alpha to zero... still makes it red π what the hell, alpha is zero, it should have no color at all π’
Blame ClearRenderTargetView π
Welp that'll stay.
Now.. It would be really nice if you could adjust the viewport and stuff, on the fly by script 
You can re-set the texture but that's very bad please don't do
Could give it a second uniqueName (for the texture, vs the other one being for the display) so you can refer to the texture and change properties on it
(Though these texture changes would then not be MP synced, unlike if changing texture string)
OMG someone must stop me
I had this issue when I did repros for drawIcon aspect rations, these squares with numbers didn't show transparency as I wanted it to
Maybe its an issue of texType?
Also why black BG by default and not transparency? π€
default is transparent I was just testing
I expected viewportX and viewportY to be in UI coordinates
As in -0.5 = half display to left
UI is in 0-1 so. yes percent then
Mh no live changing via script will also be shitty, because due to memory usage, your texture may randomly disappear and re-appear which would reset your changed values π€
Though that also happens with the display where it would already be bad/annoying π€
Live changing viewport values with script?
So texture name remains the same, with some viewport numbers in yet they they can still be different since changed by script?
I now realise what you've done 
Thought it was just RscPicture scaling or something
But its the whole thing scaling
They are just a value stored in the texture, that is re-read on every render. Nothing really stopping from changing these values (besides the complication of having to find where they are at)
Basically scripted UV Animations π
We have a couple holidays till tuesday
I'll have to do the one display multiple textures thing still.
And that scripted animation thing, I guess I'll think about it
Happy Holidays!
I'm in favor of minimizing the hud. I don't like being able to see when I'm going to be out of breath (feels mainstream-fps-like). I'd rather like right now, base it off of assumption compared to how much weight I'm carrying, but that's just me.
I'd recommend they instead focus on their scrolling action menu. Maybe color code some options? Like make the eject option on the menu red to make it more visible.
Or maybe require a shift+click for more important options
Or just get rid of the god-awful thing...
π
Use a collapsible 3D menu.
Was their any final decission on wether the amount of custom von channels will be increased from 10 to more channels?
I'd find a use for it too
itβs on back burner. the problem is that the engine is simulating all custom channels regardless of whether they are used on not. Having 10 is acceptable, more it can start to interfere with overall performance. Some kind of dynamic system needs to be implemented to allow sensible extension which means significant rewrite.
This is my blacklist for now for commands that cannot appear in short-circuit
Unary;
for, Sleep, UISleep, call
createHashMapObject (If in scheduled environment, because constructor)
- (IF in scheduled env with non-resolvable arg or hashmap, hashmap copy may call copy constructor)
waitUntil
exitWith
break/breakWith/continue will not work (technically there is no loop now that they can refer to)
try/catch
&& CODE (maybe all of && if right side is non-resolvable variable)
Binary:
call
do (switch, while, with)
forEach, forEachReversed
then
apply, select (unless right side is number constant constant), findIf, count
(These loops (and "then") could work, if they themselves can also short-circuit, or if in unscheduled, could force these loops to also run unscheduled (but then we loose break/breakWith/... so probably not))
I think that's managable. For the option to get 2x or more perf improvement if you don't use any of these blacklisted ones
Most simple select/apply loops will end up optimized
Also extra idea.
private _array = ...;
_stuff select {_x in _array;}
usually the in command has to check every iteration if the right side value is an array or object or location or string or hashmap, in order to select the correct implementation
But in short-circuit I know what type we have before running the loop, so I can move that check out
And another
groups apply {leader _x}
Currently creates one array of groups, passes that to apply, which returns another array, then the groups one is deleted.
With the new stuff, it could re-use the groups array and not have to allocate a new one π€
But performance difference of that probably wont be high
_stuff select {_x in _array;}
This one reminds me. Could arrayIntersect be re-specced to preserve the order of the left input? Currently it seems to preserve the order of the largest input, which wrecks a lot of optimisation opportunities. It's not documented so it's probably a safe change :P
Does it? I thought it retained order of right operand?
Oh yeah it does, very strange
Not strange but yes, why not, could be optimised as well a bit
Ah. It specifically takes the largest array first.
That's due to performance reasons. Its O(NΒ²) but the inner loop is over the smaller array
Though in the end its same number of iterations anyway π€
Hashmaps for the win π’
Another new optimization idea
x apply {leader group _x}
usually engine must check everytime leader is executed, if the right side argument is Group or Object or TeamMember, because depending on that, different implementation of leader command must run.
But with short-circuiting, it knows that the group command can only return a Group, so it just completely gets rid of that check on leader command.
_bigArray = [];
_bigArray resize 10000;
_bigArray = _bigArray apply {player};
[
diag_codePerformance [{_this apply {leader group _x}}, _bigArray],
diag_codePerformance [{_this apply {;;leader group _x}}, _bigArray]
]
Before: [[7.74615,130],[2.29062,437]]
After: [[7.67176,131],[2.32251,431]]
Welp, the new type check is already so much faster that this optimization doesn't make sense anymore π’ Neat!
Some benchmarking because we all love data!
With short circuiting:
45.4% of time is spent inside the Leader command (including allocating the result value)
19.7% of time is spent inside Group command (including allocating the result value)
9.5% inside diag code performance, getting rid of that result of the apply
5.2% getting rid of the temporary group value that was returned by group command
2% getting type for the type check on group command
1.7% inside the apply, pushing the result of Leader command, to the end of the array that will be returned.
Without short circuiting:
13.9% inside leader command
8.3% in group command
16.7% getting rid of the scope/callstack level that gets created every iteration of the apply
10% creating memory to store the _x variable inside the apply code (It has to re-allocate space every iteration, because it always starts with a empty local namespace. The short circuit doesn't have a namespace at all it just passes a value directly)
5.1% allocating memory to store the string "_x" (frankly we already have ways to get rid of that, must've been forgotten to use it here, I'll just fix that, same for select. hashmap apply doesn't have it because that was done right π )
3.3% inside diag code performance, getting rid of that result of the apply
2.7% for every group/leader execution, re-check if its disabled via CfgDisabledCommands.
2.4% apply setting the _x variable (short circuit doesn't have any _x variable, its resolved before execution)
2.1% adding the scope/callstack level for next the apply iteration
2.1% getting the type of the argument passed to group/leader command, to select correct version or throw type error if none found (short circuiting skips this for leader command)
1.1% getting rid of the temporary group value that was returned by group command
The time that the Leader/Group commands themselves need didn't change, just the surrounding fluff became so much bigger relative to it
I don't think I can optimize it much further. The rest of the stuff that remains must be there.
Actually.. out of the total 2% for that type check, half of it is checking if the type is a number and if yes it checks if its NaN to turn it into NaN type.
And it does that check even on my objects and groups π’
So I can shave a tiiiiiny bit more time off. If I get rid of it you wouldn't get "expected number, got number not a number" errors inside short circuited stuff.. I think that's fine. Or I can just reimplement that type more efficiently π€ but not much
jippie I saved 50% on the type check, which is like, immeasurably tiny bit faster
75% is now inside the commands itself, vs 22% before.
I can get one or two percent more but ugh. I guess supporting binary commands is next π’ then I need a two element stack
small difference, big difference.
shaved off another percent
what is this software btw?
Intel vtune
never seen that interface 
big gud
Now the fun game of shrinking 32 bytes of array (dataptr, size, allocatorptr, capacity) down to 8 bytes so I can fit more instructions in a cache line 
you meant down to 16 bytes? 
no :3 Thats the fun (I don't actually need allocator, its constant)
Just winzip them π
what about size and capacity?
8 byte data + 4 size + 4 cap
capacity is not needed as that is only needed to check if it needs to allocate when adding values.
The size I can fit into the pointer
size I can fit into the pointer
really? how?
Well.. I don't want to bother with this crap. working with 64bit pointers is fun. Making this stuff work for 32bit is ugh. So.. You'll not get short circuiting on 32bit π¨
current day pointers don't use 64bits
Also pointers are usually 8byte aligned, so there are free bits on both ends. Though I would then need to 16byte align it meh
well it's just too hacky 
yes :3
plz don't π
But its the good kind of hacky
I was about to say that the software I was working on has a cool optimization for short strings: they use a union of size and ptr and (ab)use the fact that malloc will always align allocations on a 16-bit boundary (actually 32-bit, but they use just the last nibble anyway).
So if (ptr & 0xF) > 0, then size == ptr & 0xF and the rest of the ptr is the string.
Otherwise it's a pointer to a regular allocated struct with size and the string itself.
Yes I'll do that too to store single-value directly in-line
first bit is inline flag, then 5 bits for size if its pointer to array
Actually, correction, I messed up, it's as you're saying, regarding alignment
But I need atleast 5 bits, and I don't want to align that much so I'm using the other end of the pointers.
That may potentially be unsafe if in the next decade or so we get full 64bit virtual addresses, but I'll just check for it
Too bad you have to account for both linux and windows if you're writing such hacks
well imo just do the 16 byte thing. at least it's 2x as before so it's still a win and it won't break 
For what it's worth, from my code that seems to be working π
// https://stackoverflow.com/a/48081399/6543759
// Windows does not allow allocating the bottom 64k
// Vtables will be aligned to 64-bit
// https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces
// 64bit userspace ends at 0x7FFFFFFFFFF
Not saying that you should use it, but it may be good to be aware of that (see: links)
Although that's just for win-x64
Don't need to worry about linux. It uses 63rd bit to identify kernel stuff, but I'm working with a static buffer on stack so that doesn't interfere.
And even if anything goes wrong, I'm checking if the bits are free in my buffer area
So from 150491 whichever array is on the left, that order will be used. Also the command (arrayIntersect) should be faster now.
I just realised that findAny is actually better for at least one of my use cases, so good job adding that :P
Now I just want command replacement for BIS_fnc_nearest
Roman, i think we will see just that in the next year ;)
@vague saddle There's an unspecified interaction overhaul planned in the lead-up to the Apex DLC (previously aka the expansion), hence what @wise hill mentioned
it was mentioned in the 2015-2016 Roadmap
That's great.
This notes should be on Optimization wiki page when released.
uff.
[[7.67176,131],[2.32251,431]] Office PC
[[3.826,1000],[1.052,1000]] Home PC
But still the 3-4x speedup
just apply {group _x}
[[2.922,1000],[0.542,1000]]
good stuffs.
I'd like to make a diag_ command that you can throw code into and it will tell you if it could short circuit, and if it couldn't then tell you why too
Quickly need to apply {[_x,2]}
sure thing
[[3.715,1000],[0.644,1000]]
I will probably only support a 2 element stack, which is required for binary commands. Meaning only 2 long arrays in short-circuited code
The stack size is kinda arbitrary, actually don't think it has much influence on performance so I can probably do like 8
_bigArray = [];
_bigArray resize 10000;
_bigArray = _bigArray apply {[1,2]};
[
diag_codePerformance [{_this apply {_x select 1}}, _bigArray, 1000],
diag_codePerformance [{_this apply {;;_x select 1}}, _bigArray, 1000]
];
First test with binary commands, a simple _x select 1
[[2.565,1000],[0.286,1000]]
10x improvement

;; - can be called a "vampire operator" π
The more I work on this, the more I think this should be how SQF should originally have been written π
I'm basically implementing a proper cache-friendly VM 
ok my "10x" was wrong, that's only 8.97x
But, its >10x now!
[[2.526,1000],[0.238,1000]]
Now that we can run binary commands, lets see what it does to configClasses.
Old string matching based optimization
String changed just eeever so slightly to stop the old string matching optimization
remove the checks from configClasses, and do them in a separate select, without and with short circuiting
[
diag_codePerformance [{ "getNumber (_x >> 'scope') == 2" configClasses (configFile >> "CfgMagazines") }, nil, 1000],
diag_codePerformance [{ "getNumber (_x >> 'scope') == 2 " configClasses (configFile >> "CfgMagazines") }, nil, 1000],
diag_codePerformance [{ ("true" configClasses (configFile >> "CfgMagazines")) select {getNumber (_x >> 'scope') == 2} }, nil, 1000],
diag_codePerformance [{ ("true" configClasses (configFile >> "CfgMagazines")) select {;;getNumber (_x >> 'scope') == 2} }, nil, 1000]
];
[[0.104,1000],[0.526,1000],[0.539,1000],[0.221,1000]]
First and last are not same speed because the last one still creates two arrays and iterates over the stuff twice. So once its actually integrated into configClasses itself it should be close enough to the string matching optimization.
Will do benchmarks when I get to that.
My in-game config validation tool is gonna love this β€οΈ
And a way for you to check if short circuiting works, and if not, why not.
For example, && code is blacklisted, but if it can detect that right side is bool (including resolving local variables from parent scope) then it'll let it pass
This will land in dev branch this week, for now requiring the ;; prefix. I'll remove that the week after, after we get some testing
for now for
array select code, array apply code, code count array, array findIf code
configClasses some time later, hashmap apply
What else?
configProperties?
speaking of which, is there a quick way to tell how many classes a config entry has?
there is count but it counts props + classes 
{isClass _x} count ...
π
in that case I would just do count ("true" configClasses _cfg) π
now that that is very fast, yeah π
While you're looking at configClasses, could support be added to the command for inherited entries? Or would there be no performance benefit over using configProperties with isClass _x?
"performance benefit"
Well easy to test..
[
diag_codePerformance [{ "true" configClasses (configFile >> "CfgMagazines") }, nil, 1000],
diag_codePerformance [{ configProperties [configFile >> "CfgMagazines", "isClass _x", true]; }, nil, 1000],
("true" configClasses (configFile >> "CfgMagazines")) isEqualTo (configProperties [configFile >> "CfgMagazines", "isClass _x", true])
];
[[0.086,1000],[0.169,1000],true]
mhhhh Interesting I didn't expect such a big difference
"isClass _x" configClasses changes to
[[0.288,1000],[0.174,1000],true]
The iteration code that configProperties uses is a bit more complex (which it needs to be for base-class support). Adding that to configClasses would also slow it down
Mh the most expensive part is that config properties checks if the subclass overwrote a class in its parent.
So that the class is not listed twice. That's 30% of the time spent. Cannot fix that
Or can I...
[[0.083,1000],[0.099,1000],true]
There ya go, good nuff
Please help me with testing the short-circuiting, I've tried to find edge cases but I can't find all of them.
On #perf_prof_branch I already know the command blacklist is broken, exitWith/breakWith/continueWith/uiSleep/forEach all commands that have a uppercase letter are not detected correctly. And they'll cause chaos when used inside short-circuited. That'll be fixed on dev branch (coming out this week) though
diag_testScriptShortCircuiting CODE command is there to test and see why it may be rejected
Just figured out I can easily support continue/break commands so that's already something to tweak later.
I'll post the command blacklists tomorrow
did i understand right, is the prof broken right now?
no
BlacklistedCommandsNular[] = {
("break"), //
("continue") //
};
BlacklistedCommandsUnary[] = {
("call"), //
("sleep"), //
("uisleep"), //
("for"), //
("waituntil"), /
("breawith"), //
("continuewith")
("try"), //
("breakout"), //
("breakto") //
};
BlacklistedCommandsBinary[] = {
("call"), //
("try"), //
("foreach"), //
("foreachreversed")
("apply"), //
("count"), //
("findif"), //
("breakout"), //
("exitwith"), //
("catch"), //
("do"), //
("then"), //
("setvariable"), // we don't allow modifying variables (because we resolve them before execution)
"isNil" // could set variables //#TODO can run if we check its code for blacklisted commands and var assignment
};
BlacklistedCommandsBinaryConditional[] = {
("select"), // unless right arg is scalar constant
("&&"), // unless right arg is non-code
};
These blacklists are not working right, but short circuiting is still locked behind ;; prefix anyway
Just don't try to use these
Does it matter if simple statements/code vs more complex code is tested for this testing?
ok good , I havent followed the discussion too closely to understand what you guys are doing here but it sounds good π wish I could help somehow
Doesn't matter. Do anything to break it π
There is a limit on max stack size, and maximum number of instructions, and the command blacklist.
if that is a paste, there might be a typo there: "breawith" should probably be "breakwith" (in BlacklistedCommandsUnary)
π Thank you
on that point, is "isNil" not being in () intended?
ye I got that idea while I was cleaning it up and just plopped it at the end. (it isn't actually in the current list but should be)
formatting is irrelevant
test applying short-circuiting to configClasses
Hardcoded string matching optimization.
No optimization because the string matching fails.
Short-circuiting.
[
diag_codePerformance [{ "true" configClasses (configFile >> "CfgMagazines") }, nil, 10000],
diag_codePerformance [{ "true " configClasses (configFile >> "CfgMagazines") }, nil, 10000],
diag_codePerformance [{ ";;true" configClasses (configFile >> "CfgMagazines") }, nil, 10000],
("true" configClasses (configFile >> "CfgMagazines")) isEqualTo (";;true" configClasses (configFile >> "CfgMagazines"))
];
``` -> `[[0.1727,10000],[0.4267,10000],[0.1822,10000],true]`
short circuiting is only a tiiiny bit slower than the hardcoded strings (because hardcoded true literally does no extra checking, for the fact that its actually executing script, it feels quite amazing).
And... Its universal
```sqf
[
diag_codePerformance [{ "configName _x == 'test'" configClasses (configFile >> "CfgMagazines") }, nil, 10000],
diag_codePerformance [{ ";;configName _x == 'test'" configClasses (configFile >> "CfgMagazines") }, nil, 10000]
];
``` -> `[[0.5327,10000],[0.1978,10000]]`
And sometimes the original can still be tweaked a bit when you find bad code in code
[[0.174,10000],[0.4117,10000],[0.1821,10000],true] though.. not that much
I'll add a way to run diag_codePerformance bypassing the 1 second max duration.
That's friggin annoying, if I want 10k runs then I want 10k runs please, thank you
The other hardcoded optimization of getNumber (_x >> 'scope') > 0
[[0.237,10000],[0.8096,10000],[0.388,10000],true]
yeah.. somewhat worse.
Maybe it makes sense to still leave the string comparison optimizations in there
For the extra edge on commonly used code
on CfgPatches (where the lookup for "scope" will always fail because that entry doesn't exist) its actually terribad
[[0.098,1000],[5.895,1000],[4.965,1000],true]
Any script variant suffers hard, the engine sided value reading is not affected though.
Actually, the performance impact isn't even where I would expect it to be. Its not inside the script looking up non existing entry π€
It seems to be in creating the script value to pass as _x, which the string hardcoded one doesn't have
But then it should also be the same on the other case, I probably fucked up that benchmark β³
Typo in the unary blacklist, "breawith"
Oh, someone else already picked it up.
bruhwith
Wondering if short circuiting will work with drawTriangle? π€
I was about to request drawTriangles to feed it list of triangles instead of doing them one by one
Turns out, there was a decade old inefficiency in how config values were handled...
Entry finding either uses a hashmap, or it goes O(N) through every entry comparing their names until it finds a match.
CfgVehicles,CfgAmmo,CfgNonAIVehicles are hardcoded to have a hashmap
And it can be defined in PreloadConfig class if thing is set to "fastFind". If a thing is set in PreloadConfig, streaming is also turned off (otherwise default on).
Streaming lets Arma unload configs from memory to save space, and re-load them on demand.
And if streaming is on, you run into a shitty situation.
CfgPatches is not listed in PreloadConfig, thus it neither has Hashmap lookup, nor does it have streaming turned off.
Say you had a config entry (from something that has streaming enabled), and wanted to store that config entry inside a script value.
Instead of just... taking the entry and passing it through.
The game grabbed the parent class of the config entry, grabbed the name of the config entry, then did a lookup by name inside the parent class, to re-find the entry (that it already had to begin with) to then pass that newly re-found entry along.
Arma needs to do this IF the config is unloaded but it did this everytime when a config entry CAN be unloaded, but not checking if it actually IS unloaded.
And because everything that CAN be unloaded, also doesn't have hashmap lookup. You not only pay for a needless lookup, you also pay for a needless extra slow lookup.
Before [[0.098,1000],[5.895,1000],[4.965,1000],true]
After [[0.102,1000],[1.537,1000],[0.679,1000],true]
The extreme performance difference for the first one, is because it does the scope check before creating the script value.
Whereas the others create the script value, so they can then pass it to the condition script.
You can try it π
Its only on select/apply/findIf currently. Not on forEach
About 8% of the time goes into creating and deleting the script value for _x.
What if.. we can just not do that and re-use the same value and just point it at a different config entry π Cutting out a memory allocation/deallocation for each iteration.
[[0.103,1000],[1.523,1000],[0.63,1000]]
yeah 8% alright.. not worth it π€£
Maybe having it work for forEach could be useful too, for non-returning commands
Thought I'll check if it works through select/apply
I thought forEach may be not too useful, because you often use alot more complex code in there. I need to measure the short circuiting overhead, as it will fail slot more often on foreach, but should be fast enough if the early checks fail (code too large) but if the later checks (command blacklist) may not be so nice
wouldnt it make sense to also define other root classes in PreloadConfig with todays RAM/hardware? like animations, FX
Could add some logging for which classes are looked up often, that are not in preload. And use that to see.
In practice they are probably not unloaded (because there's enough ram) but the hash index will provide speed
I can even apply short-circuiting to call and && {} code. But the overhead of checking if it can short-circuit on every usage would probably be too high
though for &&{} its probably generally worth it
Like with FX and dialogs we notice a short lag. However could be also from textures - saw BI added quite some textures to PreloadTextures
I think you can always add your own stuff to preload if you want
with a mod yep. however i think sa-matra mentioned recently the workaround he uses for missions/scripts (dummy dialog).
way back one also used to put down all vehicles/entities/created them briefly at mission start for those only created by script lag to also preload the data. not sure if thats still needed in A3
preloading the models and stuff will still be needed in A3
[
diag_codePerformance [{ true && {isNull player} }, nil, 10000, true],
diag_codePerformance [{ true && {;;isNull player} }, nil, 10000, true]
];
[[0.0007,10000],[0.001,10000]] well yeah nah.
The script does execute faster, but the overhead of building the short-circuiting is higher than the time saved, for probably most simpl-ish && CODE's
wow π€‘
diag_codePerformance uses https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170 to measure ticks.
And the resolution is 1000 ticks per second, aka one tick per millisecond
We are measuring sub-millisecond timings, with a timing function that only counts in milliseconds? π€
LOL yes indeed.
profiling configFile command.
on one run
start time 181712
end time 181712
total runtime, zero.
diag_codePerformance profiling depends on.. luck...
If clock ticks over during run, it measures higher time than what is really happening, if it ticks between runs it measures zero.
You getting a "real" timing, depends on the ratio of how often it ticks inside and between. The longer the code runs the higher the chance it ticks between.
But its all random chance based
well I'm changing it to 100ns precision 
toFixed 9;
diag_codePerformance [{true}, nil, 10000, true]
First value is with 100ns precision, second value is with millisecond precision
[0.000208420,0.000100000,10000.000000000]
[0.000207250,0.000200000,10000.000000000]
[0.000208140,0.000300000,10000.000000000]
timing is basically exactly the same, but the old code jumps between 1 and 3
lol.
And if we only do 1000 total runs
[0.000207900,0.000000000,1000.000000000]
suddenly it takes zero time π€£
config properties with short circuiting, with the new profiling thing. Code,time,percentage
[
[{configProperties [configFile, "true", true];},"0.205679","87.6"],
[{configProperties [configFile, ";;true", true];},"0.234793","100.0"]
]
``` ```sqf
[
[{configProperties [configFile, "isText _x", true];},"0.560549","100.0"],
[{configProperties [configFile, ";;isText _x", true];},"0.208435","37.2"]
]
even a simple isText does alot, neat
I'll remove the "isClass _x && (...)" string optimization from configClasses because.. meh. At the point where any script needs to execute, just short-circuiting the whole thing is better
[
[{configProperties [configFile, "isClass _x && true", true];},"0.769286","100.0"],
[{configProperties [configFile, ";;isClass _x && true", true];},"0.293197","38.1"]
]
Why is the "true" one faster than the short circuited one ";;true"? 
Because that's the older hardcoded optimization if condition == "true" That one runs no script at all
Oh I thought you said you removed it π
btw which expressions can be short circuited?
do you detect if the expression doesn't modify anything outside or...?
current limits are
- less than 16 instructions
- doesn't need more than 8 elements on stack
- cannot contain variable assignment (aka _x =..)
- command blacklist
It also depends on memory usage of the instructions (binary commands need more), it's all stuffed into a static sized buffer, currently only 512 bytes
instruction limit really only depends on that buffer size, I didn't measure how many I can actually fit
binary instruction is 32 bytes so.. ... 16 π
that 32 bytes is: 4x8 = command+2 args+return ptrs?
32 bytes
8 bytes commandptr
8 bytes argtypes table (8 bytes for single entry, 8+8*count if multiple entries)
8 bytes arg2types table
8 bytes implementation per argtype table
nular command for example is
8 bytes commandptr
doesn't need any types or different implementations.
And everything also has a 8 byte type (plus padding :/)
{;;true] ["Success",16]
{;;isPlayer _x} ["Success",80]
{;;[1,2,3,4]} ["Success",104]
I can test with larger buffer on heap, but spatial locality is quite important.
Right now they are also right next to the stack. Should probably be fine but I didn't get to it yet
why not make it an arbitrary size on the heap? 
it should still be faster than raw SQF...
I want the fastest though π
I'll have to test, I'll get to it
First making the small things work, then expand it
Eden checkbox "Place vehicles with crew" lost a few Dev updates ago and still not fixed
only on Dev branch, all ok on Prof
Is there a ticket for it?
no
do you need a ticket for it?
@full sonnet No mipmapping on uiEx?
I guess this feature is not in, or is it just unlisted as parameter?
Comparing ui and uiEx mipmap-wise and it seems to be identical
selecting a filter, no is not in, is also not listed on wiki
I expected this feature the most, to solve issue of aliasing at distance and at at angles π€
Normal textures VS uiEx\ui textures
Not selecting in particular, but having multiple mipmaps\filtering, or option to enable that in general
Well, I guess I need a way to selection filtering method then, I was trying to ui2texture the vehicles. Perhaps as flag for smooth\sharp filtering?
current sharp by default, smooth sharp depending on filtering in video settings?
Otherwise uiEx is looking great so far, no more ui2texture inside ui2texture mess needed
OK so i have finally found the REAL reason of the rage-inducing lag/stuttering that's been plaguing my A3 for the last couple of years... and no sir... its not caused by an SSD, its caused by STEAM doing a never ending 0 byte download for like 30 mins everytime i start A3 
apparently its a very old bug without any solution even up until now
https://forums.bohemia.net/forums/topic/202299-workshop-continuously-trying-to-update-a-zero-byte-file/
Video example
https://www.youtube.com/watch?v=jz4Ri0HlWbo
Can we please get this fixed? It's very stressful having to deal with this stutter every time especially when you're doing mod development where you have to open and close a3 a lot and you have to go through all that lag for hundreds of times 
I heard of this and investigated it, but couldn't reproduce and from guessing around also couldn't find any reason for it
maybe you can grab #perf_prof_branch the profiling exe, and let it profile to show where the lag is at
from some of the reports some people said its due to certain workshop items but theres not really any details what kinds are causing it
and in that forum thread someone posted their logs about repeating workshop download job
For me, stuttering disappear completely once that steam download is stopped
Yes I know, I've seen all the reports, but that got me nowhere.
I either need to repro, or I need to have someone show me what's going on (for example by running profiling)
Might be that arma integrated profiling is not sufficient, may need more advanced profiling.
But if I cannot reproduce it (which I couldn't last time), then I cannot do that on my own
Ok, i can try to help provide data
i have around 2k subscribed workshop items so im guessing certain items in that list causes this
maybe deleted/hidden workshop items that are still subscribed?
cause i had missions that cannot be played cause they're no longer on the workshop but they still show up in my MP mission list
Can you try subscribing to a whole lot of workshop items and see if the issue pops up?
"to a whole lot" that's relative.
We tried with over 200 items, and neither me nor QA could repro
probably to 2k items if possible? as i have 2087
and maybe try subscribing to an item then hide/un-public it
I can try doing this, can you give me some instructions on it
download profiling branch on steam.
Go to arma folder, and launch the profiling exe.
Go into eden, debug console, run diag_captureSlowFrame ["total", 0.05];
it will then open a popup, select copy, it copies text to clipboard, put in text file, send to me
preferably make multiple of these captures during the lagging
My advice is:
- delete the steam workshop download folder
- Never use the launcher to run the game. Use a bat
do you happen to also be using steam family sharing on the same account?
i also had the problem with the 0 byte download for a while, also with a game not downloading workshop content when it got added. it turned out to have to do with family sharing
no i dont have anything like that on
I have had this bug for a while, I heard it was having too many compositions subbed so I unsubbed from a bunch and it stopped. Resubbed to a bunch recently and the bug is back
It only starts when I load into editor/a game, doesn't happen in the main menu
It also continues after I close the game
Annoying thing is I need to iterate the instructions twice, because I need to pre-calculate buffer size.
But that's done now and its probably not too much more expensive. Maybe I can up the instruction limit till next dev branch
do you mean multiple accounts who own arma 3 on the same computer?
workshop folder gets bigger because it has to maintain the other user's different workshop items
why on earth is me running the profiling exe from cmd trying to load mods at all? It complains about @ace having missing deps
(oops, sorry for the ping!)
maybe you got mod pbo files in basegame addons folders
I found the culprit: stuff had puked into my Arma3.cfg at some point π
it was running a bunch of mods too for me for some reason, had to disable them in-game
I am currently trying to provide that profiling stuff you and exocet discussed
Thing is, I don't have any mods enabled.
aaand the cruft is back in the cfg file. where does this come from!?
Ok, moved all the profile stuff away, that seems to have helped
Ok, got profiling output, will send dm to dedmen
you need to pass -mod="" if you want no mods, otherwise its free choice and it gets stored in arma3.cfg
its a feature
ah, thanks, good to know
The profiling data for the lags helped me narrow it down to about 20 lines of code.
Problem.. steam callbacks are in there. Which widens it again to thousands of lines of code that could be the culprit, and we actually cannot use the game's profiling stuff in our steam callback code to find out which callback is bad 
[
[{[1,2,3,4,5,6] apply {continueWith 8;}},"0.002697","100.0"],
[{[1,2,3,4,5,6] apply {;;continueWith 8;}},"0.001065","39.5"]
]
π€
continue/break support maybe isn't all too useful if you cannot do if/then :/
I can probably implement my own then but uff. Though might be fun, that'd be a real if with a jump instruction π€
1k element array in _this
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"0.374090","100.0"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.063156","16.9"]
]
``` :pog:
And that even is with setting _forEachIndex every iteration (which I don't need to do)
```sqf
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"0.358731","100.0"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.056011","15.6"]
]
``` though might not even be worth to remove forEachIndex
I wonder how fast the first one is compared to arrayIntersect π
I mean _this arrayIntersect _this
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.599603","5.6"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.546255","0.8"],
[{_result = _this arrayIntersect _this;},"64.700760","100.0"]
]
huh, am I doing something wrong there?
Yes it's too fast π
1000 element array intersect can't take 64ms
Oh right π
Result:
65.1871 ms
Cycles:
16/10000
Code:
_bigArray = [];
_bigArray resize 10000;
_bigArray = _bigArray apply {;;1};
_bigArray arrayIntersect _bigArray
wuht
I wonder if it's broken after the change?
Result:
3.80391 ms
Cycles:
263/10000
Code:
_bigArray = [];
_bigArray resize 10000;
_bigArray = _bigArray apply {;;1};
_result = [];
{_result pushBackUnique _x} forEach _bigArray;
_result
something is way wonky here
Maybe arrayIntersect checks uniqueness 10000 times π
current profiling branch is 43ms vs 4.1ms
but that has the arrayIntersect update I think, I'll check on stable
2.12 stable
Result:
46.8636 ms
Cycles:
22/10000
Code:
_bigArray = [];
_bigArray resize 10000;
_bigArray = _bigArray apply {;;1};
_bigArray arrayIntersect _bigArray
It has always been so bad, wtf
Added a special case if both arrayIntersect args are the same array
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"0.368161","100.0"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.056166","15.3"],
[{_result = _this arrayIntersect _this;},"0.022143","6.0"]
]
Why is it so slow tho? π
0.02ms is big fast tho
I mean the old one
It always does O(NΒ²) iterating through full second array (which has 10k elements), for every element in first array
Whereas the new one iterates through full output array (which only has one element) for every element in first array
Actually that was 1k, this is 10k
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.579159","100.0"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.569502","15.9"],
[{_result = _this arrayIntersect _this;},"0.217386","6.1"]
]
Can you test this plz?
_new =[];
{
If (_x in _this) then {_new pushBackUnique _x}
} forEach _this;
If possible apply your optimizations too π
then isn't supported in short-circuiting because it executes code
Well still how does it compare with arrayIntersect?
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.661153","52.0"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.553641","7.9"],
[{_result = _this arrayIntersect _this;},"0.210790","3.0"],
[{_new =[];
{
If (_x in _this) then {_new pushBackUnique _x}
} forEach _this;},"7.038748","100.0"]
]
Is this the new arrayIntersect?
ye
Well I mean old one π
Is your code intentionally bad?
the in check checks against _this not _new
That's what arrayIntersect does
did you mean
_new =[];
{
If !(_x in _new) then {_new pushBack _x}
} forEach _this;
No
ah oki
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.589542","5.5"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.583446","0.9"],
[{_result = _this arrayIntersect _this;},"64.792931","100.0"],
[{_new =[];
{
If (_x in _this) then {_new pushBackUnique _x}
} forEach _this;},"7.123693","11.0"]
]
But both return the same thing right?
yeah, all of them
Well in my code forEach _this was _arg1, and _x in _this is _arg2
So if my code is faster you can write it in engine code to make arrayIntersect fast
_new =[];
{
If (_x in _arg2) then {_new pushBackUnique _x}
} forEach _arg1;
That is essentially what it does
Then why is it slower? 
except, that it doesn't abort at the first find, like in does
it goes till the end of the arg2 array, always
What for?! 
Dunno, there was some reason.
I thought I can get rid of it but I don't have the headspace to think of all the test cases to verify that doesn't break anything
Isn't it meant to return what's in both arrays? Except unique? If so you only need to check the first occurance
if I just add a if(match)break
so it stops at first match
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.580807","16.2"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.565247","2.6"],
[{_result = _this arrayIntersect _this;},"22.046898","100.0"],
[{_new =[];
{
If (_x in _this) then {_new pushBackUnique _x}
} forEach _this;},"6.964725","31.6"]
]
its still worse, wow
Just call compile my SQF code instead of the engine code for arrayIntersect π€£
Ah actually we have a "optimization" in there to try to skip iterations on the second array
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.650128","49.6"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.711296","9.7"],
[{_result = _this arrayIntersect _this;},"0.228172","3.1"],
[{_new =[];
{
If (_x in _this) then {_new pushBackUnique _x}
} forEach _this;},"7.358353","100.0"]]
with that optimization removed
I can't think clearly but could array references be a reason?
I think not 
Well if the arrays still isEqualTo compare the same
Yeah then I guess no reason π
Ah. yes that broke it
Ah because I'm not doing a pushBackUnique on the second π
But that would become slower
Say
[0,1,2,3,4] arrayIntersect [0,1,2,3,4,4,4,4]
when we get to the 4 in right side
we iterate over 0,1,2,3,4 to find that it is present
and then we iterate through the output array 0,1,2,3,4 to check and find its already in there
so we do two big iterations per element in that case
another idea
[
[{_result = []; {_result pushBackUnique _x} forEach _this;},"3.579499","49.6"],
[{_result = []; {;;_result pushBackUnique _x} forEach _this;},"0.681426","9.4"],
[{_result = _this arrayIntersect _this;},"0.238816","3.3"], // broken, ignore
[{_new =[];
{
If (_x in _this) then {_new pushBackUnique _x}
} forEach _this;},"7.222832","100.0"],
[{_new =[];
_new insert [-1, _this, true]; // arg1
_new insert [-1, _this, true]; // arg2
},"0.389969","5.4"]
]
That's wrong tho 
You're not supposed to add _arg2
I give up we'll just keep it as is and maybe potentially fix someday or not
Well mine was good π’
nu π
pushBackUnique iterates the whole output.
[0,1,2,3,4] arrayIntersect [0,1,2,3,4]
when you get to the 4 in first array
it does 5 isEqualTo's on second array, to find the 4
then it has to do another 4 isEqualTo's on the result array to find if 4 is not already in it.
the current stable branch arrayIntersect would do 1 isEqualTo on second array, and none on the result
it keeps a extra skip list to mark elements in second array that were already matched
oki...
I guess your isEqualTo check is good enough for now
Or I guess insert one is faster for uniqueness now
We have the most common use case optimized by alot now, good enough for today
_new insert [-1, _arg1 + _arg2, true] π

nvm that's wrong too 
The code really should be using a hashMap
But I don't know how the overhead of creating that map would compare to plainly bruteforcing isEqualTo's
Also out hashmap would be somewhat inefficient for that due to the intra-bucket lookups being by value and not by hash, so I'd want to write a more efficient hashmap implementation and bleeeeergh
Another alternative is also to replace the second array isEqualTo's by a hash check in a continuous array of hashes, so alot more cache friendly. But for that we would need to rely on different values always having different hash, or we'll have to do another isEqualTo on match..
All doable but I don't want to spend the time on that
nvm then... 
But either way wasn't the "all the way thru _arg2 isEqualTo" check redundant?
it is done that way so we don't need to do a unique check when inserting into output
in some cases
In my test, the in always did only one isEqualTo check
If the arrays actually have different/unique values inside them, it behaves differently
We can make the skip list thing work better but.. so much stuff that can be done it all just takes time
I'm pretty sure 90% of uses just use it as a way to get unique elements, so they'll hit the new optimization.
So making the rest faster is even less worth investing the time now
Maybe put a ref equals check first π
that is the new optimization yeah
Short-Circuiting is starting to become a bad name for what it is.
What it really is, is a more efficient script VM that just formats normal instructions into instructions for the new VM...
I kinda don't really want to rewrite the whole script engine 
Now the kinda next step is to implement a jump instruction so I can implement if
current sqf
boolean on stack
if (stack) call trueCode else call elseCode
... instructions after if/then/else block
new thing
boolean on stack
if (!stack) jump ElseCode
... instructions of then code block
Jump PostIfBlock;
ElseCode:
... instructions of else code block
PostIfBlock:
... instructions after if/then/else block
If I do that we also get && {} support
And theoretically call too if I can inline the instructions
ohh right I need to blacklist params because that sets local vars, aha!
Or I'll just have to implement local var scope, but then I only want one level of scope, the more it creates the worse performance gets again
for the new VM
Do you mind elaborating on that? I must have missed it earlier, when reading.
What new VM are you taking about? Are there actually two VMs interpreting code right now or do you just mean new code for some of the commands that you plug instead of the old one?
What is this gibberish. <@&105621371547045888>
!purgeban 617279509888106498 60d cross-posting spam, random rambling, you're better out than inside, ciao! π
*PewPewPew!!*
RIP @grave sail
Silvagni#0001 now has 3 infractions.
and btw, thanks for the ping π have a great day y'all
RE: the mipmaps that were adding for UItoTexture is a similar thing available for the procedural text?
The short-circutiing is a new more efficient VM, basically
Yes, but by "new" do you mean something that's been completely rewritten from scratch (and compatible with the old one) or new as in "the old one thoroughly improved [with speedups for specific cases added] so much that it merits to be called new"?
new written from scratch. And it converts the old instructions into new format
Woah... only a crazy person would want to... oh wait! π
can it be used within FSMs?
I feel like the lower-hanging fruit for FSM optimisation is making a way to not run them every damned frame :/
Short-Circuiting is starting to become a bad name for what it is.
What it really is, is a more efficient script VM that just formats normal instructions into instructions for the new VM...
Just invent a german word for it π
If your FSM runs apply/select/foreach/findIf then it could partially use it
ever though of adding more options for how the lightning interacts with the skyObject?
it would be nice to have the option to not have it affect texture saturation
allowing the usage of less neutral skyboxes
even if at the cost of sky quality
It has yet to be elaborated on though, like much of the roadmap... unlike this: http://i.imgur.com/2EO9IB7.gif
Project Drive 'Extract Game Data' official tool are not extracting _contact .pbo files
_tacops extracts ok, _contact no, is this normal for contact?
fixed
Mikero's ones does finely
I'm talking about official tools so on release 2.14 there would be no problem that was in the Tank dlc content extraction
in regards to testing the ShortCircuiting - is it "only" to report broken/non working things, or also performance stats or what other things?
contact still EBO no?
From what I can see in see belowArma 3\Contact\Addons: yes, it still is
Tweaked: Decrypted the remaining vanilla addons from EBO to PBO (_tacops and _contact)
I don't think we adjusted the tools yet to account for that
so both contact ebo and pbo are kept in arma3 game folder?
In the same folder?
No ebos in contact
Pbo in enoch
well that's the way it currently is yes
I thought by in "same folder" you mean pbos and ebos in the addons folder
Contact folder has the PBO's on dev branch, as expected:
The Enoch folder has been decrypted for a while now, I think that was done with 2.10?
I'd be interested in what performance improvements you can get with it
ok so A-B testing/stats
the general idea is you outsource specific operations to ShortCircuiting with the specific syntax/tag (;;) to the new VM to make use of the faster computation, correct?
should you try to keep the executions to a minimum within a SC statement, or rather get as many into it (with the said limit)? in other words is there some "hand-over" cost between the two VMs o between SC to SC?
There is cost to translate the normal instructions into SC instructions yes.
But in general its already faster to execute even if you have just a single item in the array
specific operations, well the code part of forEach,select,apply,findIf
I don't know what you mean by executions within a SC statement
my bad. not that solid anymore on the correct terminology
;; is SC till the end of the scope I would assume. so each sqf command is probably an operation or instruction - in general terms should you try to maximize those within the SC scope, or rather separate to multiple SC statements - or is this more case by case, or doesnt matter really
A whole piece of code gets short circuited. Code starts with { and ends with }
Currently during experiment it needs to have ;; right at the start.
It just makes everything faster, doesn't matter how much code you have. Having more code going faster is ofc better than having less code go faster.
In general in SQF, the less code you have the better. If you can do the same work in one loop, or split it into 4 loops. Then adding 3 more loops is adding more code and more work to do for the game
mipFilter:point vs mipFilter:linear
coming next dev @ Sa-Matra
Its quite easy and even fun to add new parameters to this syntax π
Great stuff! Can't wait to try it with vehicles!
Quick question regarding UI On Texture, when applied directly in the model as opposed to via hiddenSelections or setObjectTexture, any transparency becomes blacked out. Is there any possible fix for this? I know previously when discussing it, the face that gets the UI On Texture applied to it has to have transparency before hiddenSelections or setObjectTexture is used to apply said UI display, but since the bistudio wiki states the default UI On Texture texType should be CA one would think that that should apply transparency to the face similar to a Color procedural using CA with alpha.
You need a binarize.exe version that supports UiToTexture.. and i think it's currently plain disabled in binarize..
It checks at model pack time if the texture you supplied has transparency (it would just check what you specify as background color)
If binarize doesn't know the texture type, it probably just falls back to black
I haven't thought about that we'll have to test that. And that'll need a tools dev branch update
Well, I would be more than happy to assist with the testing. I'd love to see that become a functionality.


