Polaris

I'm having a really annoying issue where any texture (paa) I use in a GUI has a faint grey outline to it and I can't seem to remove it. The original image has been outlined in red. https://www.dropbox.com/s/alndjk9rynp4e6z/Untitled.png idc = 2027; type = CT_STATIC; style = ST_PICTURE + ST_KEEP_ASPECT_RATIO; text = "key_ca.paa"; x = 0 * safezoneW + safezoneX; y = 0 * safezoneH + safezoneY; w = 1 * safezoneW; h = 1 * safezoneH; shadow = 0; colorPictureBorder[] = {0,0,0,0}; colorDisabled[] = {}; colorBackground[] = {0,0,0,0}; colorBackgroundDisabled[] = {0,0,0,0}; colorBackgroundActive[] = {0,0,0,0}; colorFocused[] = {0,0,0,0}; colorShadow[] = {0,0,0,0}; colorBorder[] = {0,0,0,0};

Robert I would personally suggest you simply have one picture for each weapon (probably each camo variant as well), the attachments have their own preview pictures anyway. I really don't see the point of wasting time on them.

I'm basically trying to monitor the position of the mouse and move a control using the positional updates (in effect dragging the control with the mouse). I'm trying to create the ability to drag from a listnbox to a slot and have the display name or picture follow the mouse. Preferably I'd be using onLBDragging but that stops reporting as soon as you drag outside its control's area (not very useful since I can't see a way to extend the control's area without destroying its styling and creating large unpopulated columns). I can't use onMouseMoving with a control (allowing me to use direct X and Y) because the listnbox is the focus (therefore the EH simply doesn't fire if the lnb is being used). So I'm trying to use onMouseMoving with the display and it's fairly accurate but I can't seem to make it perfect for some reason, it's simply a little inaccurate, lagging slightly behind or in front, etc and the inaccuracy grows the further you drag it. I was hoping someone may have experimented with this before and may have some suggestions. Also if anyone has any ideas of a different (better) way to do it please feel free! (findDisplay 7001) displayAddEventHandler ["MouseMoving", "[_this, ctrlPosition ((findDisplay 7001) displayCtrl 2043)] call DraggingUpdate"]; DraggingUpdate = { _curPos = _this select 0; _position = _this select 1; ((findDisplay 7001) displayCtrl 2043) ctrlSetPosition [(_position select 0) + (((_curPos select 1) / 100)), (_position select 1) + (((_curPos select 2) / 100))]; ((findDisplay 7001) displayCtrl 2043) ctrlCommit 0; };

You could also probably have it as the foremost control and then simply disable it when it's not in use so it doesn't interfere with anything else but I haven't tried that.

I'm using the listbox event handlers because they suit my exact needs, even if they are a serious pain to get working properly. I have discovered a way of using onMouseMoving though which might be of interest to you if you want a non-listbox method. Essentially you need to... Create a control (probably a button with full transparency and the size of the area you want the user to be able to drag in) with onMouseMoving AND onMouseHolding assigned to it (referred to as MouseMoving control). Assign onMouseButtonDown to whatever control you want to drag (referred to as ButtonDown control). Then in the ButtonDown handler code you need to set focus to the MouseMoving control (allowing the handlers assigned to it to fire) and then in the MouseMoving/Holding handler code you need to set the position of the drag control to the X and Y reported by onMouseMoving and onMouseHolding and then optionally shift focus back to the drag control once it's been dropped (onMouseButtonUp). This method will NOT work with the listbox handlers though, but should work with any others.

Ah ok, basically the lack of documentation was the issue (once again). Use the LB/LNB event handlers for this to be perfectly accurate.

onLBDragging stops reporting when moved outside of its control BUT one of the values it reports is the IDC of the control it's currently hovering over...so it seems like this is a bug? http://feedback.arma3.com/view.php?id=19309 Edit: LBDrag and LBDrop function perfectly already so if LBDragging worked properly the whole issue would be sorted.

That's interesting, I stumbled on the 100 by accident while playing around with the values. I found that adding the safeZoneW/H division actually made it less accurate and it lagged further behind mouse movements. Try lowering your mouse sensitivity and seeing what effect it has. For me it has a huge impact on the onMouseMoving values. That's why I was leaning towards the BISimulations wiki being correct (also the "some kind of x and y delta position" doesn't really sound like it was an official addition to the wiki whereas the BISimulations one does). Plus there shouldn't really be any missed mouse movements because as soon as the EH reports I assume it resets practically instantly and if you make sure every EH that's fired is used then that really shouldn't be an issue. It'd be really nice if BIS simply told us exactly what value was being given and how to convert it accurately to actual delta X and Y (actually what would be ideal is if onMouseMoving reported the actual X and Y which would be infinitely more useful). Edit: I was trying to experiment with having a screen sized control and using the real X and Y reported from that but...you run into the focus issue again. I may try creating a separate dialog with the screen sized control and see if creating a child dialog with the lnb allows the control to still report the mouse position while having the focus on the lnb. Also note that if you change your mouse sensitivity the cursor moves at the same speed regardless BUT the X and Y reported by onMouseMoving change significantly! Meaning even if you were to create the perfect manipulation of the values so the control moved perfectly with the cursor, it would probably still change depending on the user's mouse settings. So, realising that, I may attempt to find a solution that doesn't involve onMouseMoving with a display (my only current idea is the one I posted above) unless someone can post a method of using the values that works regardless of the user's settings (*cough* BIS *cough*).

I'm reasonably sure that the BISimulations wiki is actually correct and onMouseMoving actually returns mouse speed rather than the delta X and Y as stated by the BIS wiki. But I'm also pretty sure that mouse speed and delta X and Y aren't transferable which is why the above code isn't working perfectly. "For displays or non-compatible controls the display and mouse speed x,y is returned"

By the way I'd suggest adding a unique result for if the queue is empty because returning an empty string could very well indicate a normal result. Or at the vest least I'd appreciate if you could help me implement it because so far I've tried modifying AsyncAddinInvocationMethod.cpp to no avail.

I was wondering if there was a way to use the explorer with the beta because I'm finding testing considerably arduous without it. Edit: I found the immensely beautiful Arma2Net.RVExtensionTest.exe :)

Alright, I won't waste any more time waiting, thanks for letting me know.

Alright, thank you for the information. I simply wasn't sure what type of performance impact, if any, clearing up variables would have. But I guess it's pretty logical to assume very little considering the quantity of data.

I've been wondering this for a while. I've read conflicting answers so I was hoping a BIS developer or someone that knows for sure would be able to comment? I was also wondering, if they're not, is it worth it (especially on the server) to nil all local variables at script termination to stop the system memory from becoming saturated with unnecessary and useless values?

Scott I was simply wondering if you'd made any progress with MethodAddin async? I'm eagerly waiting at the window :p.

You should either return the results row by row using LIMIT (with the max row being found using count) or, if you have a single result that is too large, you can split the actual result into pieces, return each piece separately and then assemble them (the second method requires a decent understanding of SQF and C#). It depends on what you want to achieve.

It's a reasonably complex explanation. It seems to be an issue with how Photoshop treats transparency and the game engine attempting to interpolate. Basically when you export an image from Photoshop with transparency the transparent areas are "filled" with white, obviously these are hidden by the alpha mask though so you don't actually see them. But the game engine attempts to interpolate the edges of the image to create a more natural transition and in doing so it uses the white as the colour to interpolate to. You therefore see grey/white lines around the image. To fix this you have to make sure that you fill the transparent area manually with a colour that represents the edges of your image so that Photoshop doesn't simply fill it with white. There are also algorithms that automatically "bleed" your image into the surrounding canvas that work pretty nicely. You must have a real alpha mask for this to work though.

That would probably be helpful but not absolutely required I don't think.

I believe I've managed to fix the issue. It seems to be an issue common to a lot of game engines.

Hopefully someone will eventually see this and be able to help :p.

If you have the time Scott I'd really appreciate MethodAddin as soon as possible because I'm waiting to port our whole system over to async as quickly as I can. I realise you're probably working as hard as you can, I'm simply saying I'd personally appreciate it.

That's really helpful thank you. Ah ok, great. I for one will definitely be anxiously awaiting its implementation. I'll probably get used to async using Addin but wait for MethodAddin to actually begin work.

I'm finding it a little difficult to implement AsyncAddinInvocationMethod. I'm not sure how exactly I set this as my "addin's InvocationMethod property" as instructed in the documentation. I realise this is probably a pretty basic step but there's not an example in the documentation and it's confusing me a little. Also it looks like the beta only has "Addin" and not "MethodAddIn". Is it possible to add "MethodAddin"? I much prefer the ability to specify several methods with detailed arguments rather than being restricted to the structure of Invoke.

I still haven't managed to fix this issue. Can someone from BIS please comment because I know it's an engine issue.

Humm. At least I know I'm not the only one :p.