Blue92

I've been messing around with trying different "workflows" to obtain the best result when using a RscPicture to essentially act as a custom UI, and then using the other classes to create the functionality. The issue I constantly run in to is the fact that I create, adjust, and edit the classes, in 1920x1080, in the Arma 3 GUI Editor... Then take a screenshot and move this over to Photoshop where I use the outline of the screenshot to properly match up my UI to the functional elements. Everything is going just swell, and I've converted my 1920x1080 png into a paa so it works in the Arma 3 world and stuffs... And then plop, when you look at the RscPicture the transpareceny is all sorts of fucked, and although it's hard to tell, I think the color is wacky too. For solutions to the above transparency, and possible color, issue; I simply adjust the png canvas size to 2048x1024, since this please Arma 3 for whatever outlandish reason(even if the reason is logical for this situation, it's still stupid and should have a better way of handling this). So now my colors look pretty good, and transparency is spot on... However, now my custom UI and functional UI elements no longer match up since the image size had to get all fucky. For a solution to the issue above, and the one(s) above it, I can launch my game in 2048x1024, create, adjust, and edit the classes in the Arma 3 GUI Editor... Then run it through Photoshop, as an already 2048x1024 image, convert it to a paa, and boom bada bing it's not too bad when I relaunch my game in 1920x1080, however the fucking UI is scrunched up horizontally, and expanded by like one noticeable pixel vertically. So it's still not a good route, but, probably one of the best to maintain a good connection between the custom UI and functional UI elements. Surely... I'm an idiot, Arma 3 really lacks quality guides that are linear and to the point, and there's a better solution to the first problem of transparency and there's no need for all the extra wazza pappa I was doing to try and solve it?

While working on a dialog of mine, I was trying to use the below code to freeze another friend of mine on the server. _selectedIndex = lbCurSel 1500; _selectedPlayer = (PlayerList select _selectedIndex); hint format ["Index: %1 Player: %2",str _selectedIndex,str _selectedPlayer]; if (_selectedPlayer getVariable ["pVar_Frozen",false]) then { _selectedPlayer enableSimulation true; hint format ["You've unfrozen %1!",_selectedPlayer]; _selectedPlayer setVariable ["pVar_Frozen",false,true]; } else { _selectedPlayer enableSimulation false; hint format ["You've frozen %1!",_selectedPlayer]; _selectedPlayer setVariable ["pVar_Frozen",true,true]; }; On my client, my friend was frozen, but would "vibrate". I thought it was weird, and since he didn't say anything I asked if he was frozen, and he told me he wasn't, which is why he was "vibrating" I guess... Server trying to move him on my end, yet he'd kinda not movable on my end. I've tried enableSimulationGlobal, and that seemed to work even less. Do I need to use remoteExec, and for the target, set my selected player as the target?

There are mods, but, none of them should be effecting the displays, I think? Sorry, really new to all of this. I'm not executing them in the debug, maybe that's why we're getting different results? Edit/Solution: I wasn't able to figure it out other than I summed it up to some kind of timing issue. I just did the below, and it worked fine, just being picky is all, thought I was missing something important. [] spawn { waitUntil {!isNull findDisplay 49}; ["Terminate"] call BIS_fnc_EGSpectator; (findDisplay 49) closeDisplay 1; waitUntil {isNull findDisplay 49}; };

The below code works just as you assume it would. The spectator is closed, the escape menu is opened, and then closed. [] spawn { waitUntil {!isNull findDisplay 49}; ["Terminate"] call BIS_fnc_EGSpectator; }; [] spawn { waitUntil {!isNull findDisplay 49}; (findDisplay 49) closeDisplay 1; }; The code below however, won't close the escape menu, and I don't understand why... Is it simply because it gets executed too fast? Wouldn't display 49 already need to be open when it gets there though? Why do we need to wait, again? [] spawn { waitUntil {!isNull findDisplay 49}; ["Terminate"] call BIS_fnc_EGSpectator; }; [] spawn { (findDisplay 49) closeDisplay 1; };

Looking to see if there's going to be any further updates for this? A lot of servers seem to have moved back to I&A. :\

Nice job mate, pip pip.