byrkoet

I get a malware warning (possibly false positive?) It corrupts the zip archive though, so it is kind of a nuisance for testing out your tool. Might want to check it out.

I might be noticing increase in FPS, but then again, I am playing with very few people. Though I really like 1st Person View Wasteland servers so join me on EU-02-B !

Thanks a lot, I forgot about that.

I want to stop a unit at a certain waypoint for a certain amount of time before having him continue. Though I do not make use of the TIMEOUT of a waypoint, because the action has to be immediate and has to stop an animation, so do not bother with this please. Instead of using an addWaypoint command and setting waypoint type, I just made a function that disables the unit's animation and after a sleep, enables it again - like so: TAG_fnc_disableAI private ["_a", "_t", "_s"]; _a = [_this, 0, objNull, [objNull]] call BIS_fnc_param; _t = [_this, 1, 5, [0]] call BIS_fnc_param; _s = [_this, 2, "move", [""]] call BIS_fnc_param; _a disableAI _s; sleep _t; _a enableAI _s; hint format ["\n%1\n%2\n%3", _a, _t, _s]; //I made sure the function is working. To give you a complete idea: I have added that function in the init line of the waypoint - like so: Waypoint's initialization input [this, 30, 'anim'] call TAG_fnc_disableAI I could use some help here and I would highly appreciate it ;)

Just like that; You can use safeZoneX for left placement and -safeZoneX for right. contrary to the description, parameters for BIS_fnc_typeText are: array with arrays of text and format, position x, position y, global format So it is simply a positional variable that positions the text.

I am aware that there is a spotting mechanic in place and that sharing of a target's coordinates is also functioning, read the last (totally not sarcastic) line: I am just pointing out that AI should have a cone of vision instead of a certain distance from where they will spot you, with a delay. To illustrate the technique I propose: This illustrates how the AI should 'see' their surroundings. And not just spot enemies if they get within a certain distance or some workaround to simulate the cone of vision technique poorly. Even if the AI receive information (heading), they shouldn't know for sure that you are there. Example: there may be tall grass or a bush between you two. So the AI should try to walk around the bush or stand up to see over the tall grass.

Some good points have already been noted, like: - More specific AI configuration; - More specific skills that can be adjusted; - Better usability of adjusting skills; - A more exponential curve for a skill like aiming. But most importantly, the AI themselves should have a new feature, namely: A coneOfVision sort of config command, where there is an actual line of sight between a target and AI. Arma 3 makes use of the sun shaft technique and that illustrates a very good line of sight characteristic. That is the exact way an AI should 'look' at his surroundigs - instead of shooting you in the face through bushes (mind you there are no other teammates, who could have told him the coordinates of your face).

It can be done a lot easier with the mission editor tools: - Use triggers to make sure a certain playMove animation is executed. - You can spawn the smokes with the same trigger using createVehicle - I believe. PS I just noticed I used an Else-If-statement, but I believe those aren't supported. I have edited the opening post just in case you need a reference.

Edited: if (isServer) exitWith {}; _aircraft = unit1; _vehPlayer = vehicle player; _heightPlayer = (getPosATL player) select 2; _heightUnit = (getPosATL _aircraft) select 2; _heightDiff = _heightUnit - _heightPlayer; //--- conditions for player and unit1 if (_aircraft isKindOf 'air' && isEngineOn _vehPlayer) then { if (_heightDiff > 5) then { // if unit1 is an aircraft, player has engine on and their height differs move than 5m _aircraft playMove 'moveName'; }; if (_heightDiff < 5) then { // if unit1 is an aircraft, player has engine on and their height differs less than 5m _aircraft playMove 'moveName2'; }; }; //--- EH for checking engine state player addEventHandler ['engine', { _engState = _this select 1; //--- engine off ---> moveName3 if (_engState == false) { _aircraft PlayMoveNow 'moveName3'; sleep 1; } }]; //--- landing > 1m away from unit1 ---> moveName4 if (_heightPlayer < 1 && (_vehPlayer distance _aircraft) > 1) then { _aircraft PlayMove 'moveName4'; } I have tried to implement your logic as good as possible. Since I am not sure what the scenario is, I wasn't able to make the script consistent with the gameplay. So you have to make sure it all runs when needed. I haven't tested it myself and it is most likely not functioning, but I figured I could at least contribute :).

Exactly, and above all: we already argued about the vignette that could be enhanced and the breathing sounds possibly made better.

Well, simple isn't the question really... I figured since it is for a future build, the dev branch would be a nice place.

Definitely not blur. Vignette would be sufficient if we're talking about quite a run while carrying extreme loads.

Why haven't I seen anything about this? The campaign seems to be made using the same tools available to us, meaning it is simply a mission with more advanced paths. I suggest the devs simply add the campaign mission to the multiplayer. Or make a quick setup where the campaign is to be able to join a 'session'. Perhaps they have no time to spare making it available as a multiplayer scenario. So how about we figure it out by our selves. I took the liberty to locate the necessary files. The episode: survive files are located at: ...\Arma 3\Addons - missions_f_epa.pbo - missions_f_epa_data.pbo - missions_f_epa_video.pbo My issue has been that the missions seem to be packed and they transition with code I can't seem to point out. Anyone have a clue how to remedy this? I believe they have done this, because the mission can get quite a cluster of paths and scripts they have to keep track of.

I am one of many people in my group who find that the values regarding fatigue should be pared with real data for comfortable play, since stamina is a major requirement for the military. How is that achieved? Well, consider the following first: A soldier needs to fulfill a set of requirements. I have rounded the requirements of a few armies, including but not limited to the US army and the Armed forces of the Netherlands (source: US Army & Armed forces of the Netherlands. The latter being a consideration.) The stamina tests require you to make a certain distance within a certain amount of time; with or without added weight. So if you consider that, than you'll have pretty robust fatigue over distance values. Note: the difference between running and sprinting is that sprinting is your maximum performance, arguably around 25km/h with no additional weight. The rounded figures would, though arguably, be somewhere around the following: Distance requirements, with or without additional weight. 50 minute run + additional exercises (the latter noting that the soldier should not be at full fatigue); 50 minute run carrying ±25kg (didn't note any additions, so full fatigue is probably considered). A distance over time requirement ±3 kilometers over 1/4 hour (so with a floor average of 12km/h. About half of maximum performance, so we'll work for simplicity's sake with half its value). To conclude the few figures above, you'll be looking at something between the lines of these: - Full fatigue, meaning you'll be forced to march, is achieved after 6 minutes of sprinting. - Full fatigue with an addition of 25kg is achieved with about 1/4 of the above: 1.5 minutes of sprinting. Since comfortable play with a realistic feel is desired, we want the weight to be steep, but range from an average weight. So the steepening should begin after a weight of say: a minuscule backpack, completely filled minimal gear and an assault rifle. That way players will notice they are carrying something out of the ordinary and they will experience the need to stand down some items. Noticing - that is another point, a very crucial one. Visually acquiring information about the 'weight' you are carrying is pretty well done in Arma 3. Since you don't have a scale with you all the time - obvious me is obvious. So no criticism on that part, rather a compliment. I find it to be very well done, since volume is objective and weight isn't - for obvious reasons (muscle groups... there I go again). Alright, back on track. Since I now have given desired values for fatigue by sprinting to be able to play comfortably. I'll probably have to get to aiming. I'll start with a bold statement, but a rather true one: Weapon sway isn't the product of fatigue in the direct sense. One can focus and control his/hers need for taking a deep breath, but that ability differs considerably. As well as the ability to cancel out the need of acknowledging pain when shot (which is another multiplying value for imprecision in Arma 3, check the config), is also arguably different per soldier. Knowing this you'll either say I am wrong, or you'll say that the imprecision algorithm has to change for the worse. Well, I'd have to object to both. It is fine, because we just want comfortable play - that is all really. So I am suggesting that both fatigue and damage should have less of an impact on sway while aiming down sight. That also goes for the weird sounds infantry units make. I have never heard someone breath that awkwardly - seriously do something about it. (tl;dr) So I have often noted that I and many players who I speak with regularly just want comfortable play. Playing in the shoes of a real, well trained soldier. Not some coach potato in a military outfit. I might have just written the previous sentence rather than the whole thing, though I figured I should share my order of thought before I suggest something in the first place.

Thank you very much, David. Ineed, the double quote marks in description.ext are highly necessary. This line, in your init.sqf should be avoided as of version(dev) 1.01.110133. WaitUntil {Sleep 1; local player}; It merely returns an error and wouldn't spawn any character correctly. Another little syntax error (which I dindn't have previously) was that I had a space afer the weapons array: weapons [] = { 'binocular' }; Apparently such a space is not allowed and so I avoided another error. Oh, and one minor thing I noticed: the order in which you add the respawnPosition function in the init.sqf will be the reversed order of spawning if the menu is unavailable, as for example in the editor. Furthermore I have used small grascutters to serve as spawnpoints, since they count as units. It was indeed a very viable alternative, thank you for that suggestion aswell. On the other side it is a shame that the spawn points are titled 'NO AI' or something of that fashion, but it won't be a bother. As such, thank you very much for helping me out!