Moldisocks

I agree completely, Mission makers should have the ability to change the balancing features, but by default they're set to the most realistic settings.

Nothing but my opinion, that's all: The rounds for the jets that i assume you are talking about (Wasp, Shikra and maybe Gryphon) are armour piercing and shouldn't explode on impact. Besides, i think that the fact that they don't show you if you have hit you target is an interesting mechanic that will make it harder to targets, which might help to balance the new, already OP jets.

@R0adki11 Yeah i understand this for some of my points, but there are still alot of things that need to be changed in the actually game, not within the mission. The damage model, the titan missiles and the laser designator make the jets over powered for any PVP mission. @oukej Ahh ok, so this is being worked on and might be changed in a later update? Also where you have said I understand this for things like the jets loadout (Including flares and designators), but what i said here: This cannot be easily modified by the mission creators, and i think it needs to be reworked. @WurschtBanane Yeah ok, maybe the laser designators are only on the australian servers, which wouldn't supprise me, they have been having alot of admin issues lately. Was it reported via the forums? if so can i please have a link to it. Nah, maybe it had been buffed with the after the DLC released idk, but it is nothing like the old damage model where I could easily take on three or four enemy player controlled jets trying to take me out. Wipeout could take around 6 hits before being red hulled and then another hit or two would usually destroy the jet. Neophrons were much weaker and Buzzards were always impossible to hit XD. As for knowing how to use the missiles correctly, the way that it had worked in the past (which makes total sense) was that you would fire the missile as the jet was either flying over you or doing a gun run on you (flying towards you in someway). Now as soon as the enemy jet flares even one flare, the missiles just does a u turn and ignores the jet (unlike how it was, where the missile would follow the flare's heat signature). Yeah sure i agree it's realistic, but in any PVP gamemode with more than 2 jets on each team, the current air to air combat dynamics have been noobified. I respect the fact the you and BIS want to have a highly realistic game and im all for that, but there needs to be an option for mission makers to change alot of the aspects about the radar (radar range, locking range, etc..) so that mil-sims can be made for realism and PVP gamemodes can be less realistic for the sake of gameplay complexity and diversity. Thanks.

COMPLAINT: I know i am not the first person to say this, but i've been so frustrated with the jets DLC since release. I imagine that the jets dlc is good for mil-sim missions and missions alike to that, but for gamemodes like KOTH, the new jets DLC has ruined to game. It is now noobified, anyone can just get up in a jet, lock and fire 4 missles at a target and win a dogfight. This causes the air supremacy game mechanic to turn into ' which ever team has most jets in the air wins', no matter the player's or the jet squad's piloting skills. This noobification has resulted in many players that used to player arma 3 everyday on the gamemode of KOTH to leave (i know of atleast 7 of my friends that have left due to these changes). The ease of use isn't the only issue that came with the new jets DLC, here are some other issues; - Both the cheetah and the tigris are both useless at defeating the new jets, even the neophrons and wipeouts aswell. On many occasions, i have attempted to gun down an enemy jet as they were slowly flying above me, i have counted each time that i had hit the jet around 10 times with the 35mm AA rounds. The bullets that impacted their jet didn't seem to matter, as they then proceeded to bomb my Tigris with GBUs and carry on flying with no issues. - Besides the AA vehicle's Cannon, their AA titan missiles are also useless against the jets for two reasons. 1) the new jets have a lot of flares, and the amount of times they can use countermeasures can be increased by switching between burst and single. 2) As soon as the enemy jet flares, the titan missle veers of course drastically, not even attempting to follow the heat signature of the flares themselves. The combination of both of these things, means that the titan missiles on the Tigris and Cheetah are now useless (jet can virtually continuously flare which will automatically make the missile fall to the ground. - Because the jets all have a laser designators built-in, any jet with a GBU will easily dominate ground targets like cheetahs and tigris's, meaning they can now both dominate the air and the ground with no risk of being killed. AA MANPADs are the one saving grace though, as they seem to be the only SAM system that can take down the new jets. SUGGESTIONS: I would suggest that the new jets have less flares, are unable to laser paint their own targets and most importantly, the methods for taking down the jets has to be buffed, such that the Cheetah and the Tigris are actually effective towards the jets (maybe make the 35mm Rounds more effective towards air targets, almost as they were before).

Well why not just use your own defines? The ones you have listed, and the dialog cfg you have shown, both look fine. If it is working with both those, don't bother trying to use those defines that MKD3-FHI showed.

HOLY balls, how did i not see this, sorry was soooo tired last night when i did this haahaha, sorry for wasting everyone's time.

OK so _primSel is a variable defined by a listbox selection, it will return the index of the listbox entry selected. _primSel = lbCurSel 1500; i have checked to make sure that _primSel is outputting the correct index using systemChat str([_primSel,_secSel,_gadgSel,_perkSel]); the array returned (depending on listbox selection is something like this) [3,2,1,3] so i know that _primSel is correct. Even when i don't use _primSel and i manual put in a number like this systemChat str(((loadoutarray select 0) select 2) select 2); It returns nothing.

Hey, i am having trouble with an array, and extracting information from it. my array is this, soorryy it is quite long: And when i try to get a specific weapon class name from the first element of the array using this: _primary is nil. i have no idea why, and i need some help. Maybe a second pair of eyes can help.

ffs, haha went through all that shit above, yet there is a EH for exactly what i needed. Will modify script. Thanks @JSD, like the other time great replies and solutions.

Awesome, did you get answers to your questions that worked? I was attempting to check which spawn point is selected by the player every 0.2s, by using the lbCurSel command in fn_selectCamPosition function, and if the player had selected a new spawn point, then the camera pos and target will change so that it will show an overview of that spawn point. The original fn_spawnMenuCamera function was run constantly and therefore constantly created new cameras, i am currently working on new script that will just check the variable, instead of creating a new camera and checking(possible fix for the script in last post). So yeah don't want to create a new camera every 0.2s, i want to check which spawn point is selected by the player and then setPos of the camera depending on the selection.

@JSD You are becoming an avid reader of my threads haha. ok i will try this later today, see what happens. I have a feeling that i still will not work, just because of the fact that there are 1.7 million cammera indexes. This is because i am looping my camera creation script constantly, this must be fixed. Would something like this work to fix the constant camera creation? in fn_spawnMenuCamera: The above script will still be executed constantly, which will allow for the constant checking of the selectCamPosition, but will not create infinite cameras (if im not wrong). Thanks for the reply

Hey, i am making a mission where i want a menu to be displayed over the top of a specific camera and camera angle, the menu will allow the player to select their desired spawn point and then click spawn (image of menu below). The menu and the camera angle scripts are wokring perfectly (for what i need them for), but when i press spawn, the player is moved to the designated spawn area, but the camera stays in roughly the same position (i say roughly, because for some reason it seems to change FOV and move slightly down). The way the code works is explained further down in this post. The menu and the camera angle are made by calling menuInit.sqf when the player is initialised (so player will see this menu and camera as soon as they enter server). The ListBox is populated using the above code aswell. The while do loop in the above loop will call mld_fnc_spawnMenuCamera constantly as long as menu is open, so that i will check which check box is selected (just realised while writing this that it is very inefficeint way of doing this, and i realised that during testing i had made 1786345 cameras XD, but i decided to keep this code in here anyway as a place holder). Once the player selects the Spawn button a function called fn_spawnPlayer.sqf is called: this function should move the player's unit to the designated point, close the menu and destory the camera. This function was supposed to do those things and return control on the player's unit back to the unit and then change the camera to the player's unit (basically switching the camera back to the unit). destroyCam is one of the main reasons as to why i started this topic. I using destroy camera the best way to get rid of the menu's camera and return to the player's POV (and give controls back to the player. If this is not how you would do it at all please suggest a better way of doing it. Thanks

Ok thanks, i will try to consider using safezones for my next GUI see what happens.

Ok wow this helps alot, i knew i had to define the GUI_GRID just didn't know how.

As most of the people that will by using my GUI have 1080p screens or higher, then im not tooo worried about the whole safezone thing. For this reason i used absolute values when i remade my GUI, it now works perfectly. Thanks anyway Yeah thanks for this, i have seen some of KK's GUI blogs, i have used his Hex to arma color converter a few times, it is very handy. Thanks again