pd3

I'm preparing to create a mission with multiple objectives including a recruit/rescue portion, and I was simply going to port over a pow rescue script that I originally used in an A2 mission I had previously created however it no longer works. I have looked, however to no avail to find a set of scripts which will meet some of the criteria necessary to work with the mission I'm creating. Some of the criteria I would like to meet for using a given script include - Remove recruit/rescue addaction on creation (surprisingly none of the methods I've encountered I've found do this) - Script activated enableai "move" command from any location in the mission area for the subject once they are recruited (subject has a random chance to spawn in multiple locations) - AI must behave no differently than another squad member once inducted, also targetable by opfor ai This aspect of the mission entails investigating various suspected locations of the individual requiring rescue, with each location having its marker removed upon investigation (this part already works). I'm going to keep fiddling around and try to make it work, but if anyone has any tips or insight, I'd be appreciative of the help.

I can't seem to find this very useful tool for download anywhere. I'm really hoping there isn't some kind of shift in community attitude toward editing binarized config files.

I found a script that I've been using for manual garbage collection of nearly everything from bodies, dead vehicles, weaponholders, smoke shells, etc. However I need something simple that can check for an empty vehicle and delete it either from a radius around the player or within a trigger. I'm currently using a spawning system that supposedly has a garbage collection system that doesn't seem to be 100% effective. My solution for this was to package a script wherein I could activate it from a radio command and manually ensure certain things are removed to ensure optimal performance. The only bit I haven't figured out how to include is uncrewed vehicles as there's no actual command iirc to check for a vehicle that is empty like there is an "alldead" command to check for both dead bodies and vehicles. It doesn't need to be fancy, nor run on a timer, I'm explicitly trying to avoid that, just something I can manually execute to shore up anything missed by the spawn system's existing garbage collector. Any help in this matter would be greatly appreciated.

When it comes to dealing with existing code, I'm not so inclined to get into territory I'm not familiar with, and one unfortunate problem for me that has always been an issue with myself and coding is appropriate syntax. Unless, I had access to previous examples of how to do that effectively, I'm inclined to avoid it. The more abstract the issues with syntax becomes, the more I seem to fail at it. I'm not sure if that's what you're advocating, but I really just want something completely external to the existing spawn scripts (if possible) that I can use to get rid of unwanted objects in field manually. I just don't have enough confidence in my abilities to script to dig that far in without screwing the whole business up, I can decipher some code and script as long as it isn't exceedingly abstract and I can simply do the legwork and figure out what it all means. Syntax on the other hand is where I get hamstrung when writing it myself, and I know my limits. With regard to this cleanup = player nearEntities ["landvehicle",14000]; { if ({alive _x} count crew _x < 1) then { cleanUp set [_forEachIndex,objNull]; { deleteVehicle _x } count (crew _x); deleteVehicle _x }; } forEach cleanUp; cleanup = cleanup - [objNull]; diag_log "--------"; { diag_log _x } forEach cleanup; Especially the last few lines Is this supposed to display a log or write to a file any details? I tried executing in the code in the debug console and once more in the small test-area I used, it seemed to work fine as well (it however did not display any additional info). Also, I still would like to be able to activate something like this via trigger and script ideally. It doesn't seem that's possible in its present form. If I'm able to get everything set up as I would like I will continue testing the scenario I've created, as it stands I've basically created a few temporary test missions to see if the script works (which it does).

Yes, Dragonfyre is a sound mod, but it uses scripts in the earliest version. That was really only of peripheral interest, I'll have to do my own experiments to see if removing #particlesource objects helps any. https://forums.bistudio.com/topic/155690-ai-spawn-script-pack/ Presently I'm only using the Ambient Combat set of scripts. The thing is, I have encountered abandoned vehicles which should have been removed at some point if the integrated garbage removal script actually does so, it doesn't seem as if LV_fnc_ACcleanUp.sqf or LV_fnc_removeDead.sqf do so at least. After a fairly long period of time of playing the mission does seem to start abnormally slowing down to a considerable degree, saving and loading after restarting does not seem to help, so I'm not sure it's memory related. I suspect a lot of unculled objects are left after some time and it might help if they're deleted via script when performance starts to degrade. { if ({alive _x} count crew _x < 1) then { { deleteVehicle _x } count (crew _x); deleteVehicle _x } } forEach (player nearEntities ["landvehicle",14000]) This worked really well run from the debug console, thanks. How would I do to get this to be executable via a script?

I think one thing that might be screwing me over, which I hope my script might get rid of is the fact that I'm running the old script-based version of Dragonfyre (I know it's old, but I like it and I'm slow to accept change) for some of the effects it creates a #particlesource object and then plays a sound. I'm wondering if over time it just creates and does not delete a whole ton of these, which is why I included this into the array to potentially eliminate that possibility. { deleteVehicle _x; } forEach allDead; { deleteVehicle _x; } forEach nearestObjects [getpos player,["WeaponHolder","GroundWeaponHolder","WeaponHolderSimulated","SmokeShell","#destructioneffects","#particlesource"],14000] Also I'm interested in what das attorney had mentioned about preferring nearEntities vs nearestObjects I found this on the BI wiki So it seems that for deleting "dead" things nearestObjects is still necessary. Does anyone know which one should be used to get rid of #particlesource objects? Also, I don't really know if I have the chops to go digging into somebody else's code and change it in such a fundamental manner, the included garbage collection system is already beyond what I'm capable of coding myself. I was told however that certain aspects of the script compilation simply aren't up to date and don't work properly, what I'm doing is basically a stop-gap solution for the time being.

I wish the script-supplied garbage collection was a bit more thorough for the dynamic spawn system I'm using, but it works pretty good all the same. I just basically want a manual in-game "reset button" that can eliminate sources of performance decline (which does seem to inexplicably increase in spite of the included garbage collector) when you have numbers of groups spawning in and out, dying, abandoning vehicles - over time. I'll definitely set about implementing the suggestions supplied and see how it works out.

Thank you for the reply. I was thinking of something that looks something like this, although this isn't specifically functional itself. _vehicles = nearestObjects [player, ["landvehicle"], 14000] if (count crew vehicle _x == 0) then deleteVehicle _x forEach _vehicles; Would a concept like this be workable?

Does this script perpetually run or can it be made to only run once at a time when something like radio alpha is called? I would prefer to personally have control over when this script runs for efficiency's sake.

The ambient combat module works alright, which is nice, but there are some things that could use improving. I personally would like better control over maximum units per group for vehicles and squads when spawning. The script would work better if there were more groups with a reduced overall limit of total people per-group. As previously mentioned the aircraft kind of need to be fixed because it's way too easy for them to fly out of bounds and spontaneously blow up, but overall it inherits the legacy of ThomsonB's Flashpoint script set well enough. In fact if anyone were interested, it would be helpful if somebody could offer a solution to creating a min/max constraint to the random squad generation routine. private ["_BLUmen3","_OPFarrays","_BLUarrays","_INDgrp","_INDhq","_INDmen","_OPFmen2","_BLUmen2","_pos","_side","_size","_BLUmen","_OPFmen","_men","_amount","_BLUhq","_BLUgrp","_OPFhq","_OPFgrp","_grp","_i","_man1","_man","_leader"]; _pos = _this select 0; _side = _this select 1; _size = _this select 2; _grpId = if (count _this > 3) then { _this select 3;} else {nil}; _BLUmen = ["B_Soldier_A_F","B_soldier_AR_F","B_medic_F","B_engineer_F","B_soldier_exp_F","B_Soldier_GL_F","B_soldier_M_F","B_soldier_AA_F","B_soldier_AT_F","B_officer_F","B_soldier_repair_F","B_Soldier_F","B_soldier_LAT_F","B_Soldier_lite_F","B_Soldier_SL_F","B_Soldier_TL_F","B_soldier_AAR_F","B_soldier_AAA_F","B_soldier_AAT_F"]; _BLUmen2 = ["B_recon_exp_F","B_recon_JTAC_F","B_recon_M_F","B_recon_medic_F","B_recon_F","B_recon_LAT_F","B_recon_TL_F","B_soldier_AAR_F","B_soldier_AAA_F","B_soldier_AAT_F"]; _BLUmen3 = ["B_G_Soldier_A_F","B_G_soldier_AR_F","B_G_medic_F","B_G_engineer_F","B_G_soldier_exp_F","B_G_Soldier_GL_F","B_G_soldier_M_F","B_G_officer_F","B_G_Soldier_F","B_G_soldier_LAT_F","B_G_Soldier_lite_F","B_G_Soldier_SL_F","B_G_Soldier_TL_F"]; _BLUarrays = [_BLUmen,_BLUmen2,_BLUmen3]; _OPFmen = ["O_Soldier_A_F","O_soldier_AR_F","O_medic_F","O_engineer_F","O_soldier_exp_F","O_Soldier_GL_F","O_soldier_M_F","O_soldier_AA_F","O_soldier_AT_F","O_officer_F","O_soldier_repair_F","O_Soldier_F","O_soldier_LAT_F","O_Soldier_lite_F","O_Soldier_SL_F","O_Soldier_TL_F","O_soldier_AAR_F","O_soldier_AAA_F","O_soldier_AAT_F"]; _OPFmen2 = ["O_recon_exp_F","O_recon_JTAC_F","O_recon_M_F","O_recon_medic_F","O_recon_F","O_recon_LAT_F","O_recon_TL_F","O_soldier_AAR_F","O_soldier_AAA_F","O_soldier_AAT_F"]; _OPFarrays = [_OPFmen,_OPFmen2]; _INDmen = ["I_Soldier_A_F","I_soldier_AR_F","I_medic_F","I_engineer_F","I_soldier_exp_F","I_Soldier_GL_F","I_soldier_M_F","I_soldier_AA_F","I_soldier_AT_F","I_officer_F","I_soldier_repair_F","I_Soldier_F","I_soldier_LAT_F","I_Soldier_lite_F","I_Soldier_SL_F","I_Soldier_TL_F","I_soldier_AAR_F","I_soldier_AAA_F","I_soldier_AAT_F","DLCG_Orthes_IA_soldier_chef_equipe","DLCG_Orthes_IA_shotgun","DLCG_Orthes_IA_soldier","I_G_Offroad_01_armed_F"]; _men = []; if(typeName _size == "ARRAY")then{ _amount = ((random (_size select 0)) + (_size select 1)); }else{ _amount = _size; }; switch(_side)do{ case 0:{ _men = (_BLUarrays call BIS_fnc_selectRandom); _BLUhq = createCenter west; _BLUgrp = createGroup west; _grp = _BLUgrp; }; case 1:{ _men = (_OPFarrays call BIS_fnc_selectRandom); _OPFhq = createCenter east; _OPFgrp = createGroup east; _grp = _OPFgrp; }; case 2:{ _men = _INDmen; _INDhq = createCenter resistance; _INDgrp = createGroup resistance; _grp = _INDgrp; }; }; _i = 0; for "_i" from 0 to _amount do { _man1 = _men select (floor(random(count _men))); _man = _grp createUnit [_man1, _pos, [], 0, "NONE"]; }; if(!isNil("_grpId"))then{ call compile format ["LVgroup%1 = _grp",_grpId]; }; _leader = leader _grp; _leader

@oldbear It's funny that you mentioned the disparity between the Pentium 4s of old versus comparable AMDs, I remember those days, and I didn't experience much of an issue with OFP, however comparing other games, specifically Morrowind performance on my machine and to that of a comparable AMD processor of a friend's, I had absolutely game-wrecking stuttering whereas he had none at all. It was extremely frustrating as my graphics card, processor and ram were not inexpensive. It does seem as if the tables have turned, and I think my next build will have to be intel and nvidia. Also, thanks for all the info, I'm glad I've hung on to 1.58, I just don't think based on how I play the game would be playable with a 10-20 FPS drop, and the sorts of missions I play are at the absolute minimum threshold of what I would consider enjoyable, so "scaling them down" - simply isn't an option.

Oh well then. That would also explain my issues as well, my crossfired 6970s have done their job well enough during their heyday, but I can see how that simply wouldn't carry the additional "weight" imposed upon them, they're older cards. I'm simply going to stick with what I know my system (and myself) can tolerate in terms of performance. Back in the good old days if you didn't like a certain update, so long as you had them archived you could just reinstall and update to whichever version you preferred, the risk is far too great now for personal experimentation.

Where specifically have I touted proven facts? AMD has opted for an awkward architecture that doesn't seem to be easily accommodated, phenom IIs are simply getting older on top of that. That alone would indicate that there's simply not much left to squeeze out of them performance wise, similarly my graphics adapters are getting older, in spite of serving me quite well for it's original purpose (playing Arma 2). I did not perceive how much more performance could be optimized out old older, more awkward hardware with this new update, when faced with people who run AMD systems pointing out that they're seeing definite reductions in overall performance even post-optimization, I think my suspicions were well founded, and that's all I really need right now. Granted I do not have an exact replica of this machine to compare performance to, and I'm absolutely not going to dick around with moving gigs of data updating and trying out the new update and then moving around gigs more information back if I don't like it and then having to defragment my HD. Perhaps I am missing out, but the risk of that estimate being wrong is far worse than simply being happy with what I know works for me. I'm the kind of person who will walk away with what I know I can be happy with than risk anything knowing I might end up with something I'm not. That being said, I'm fairly confident there's really not much BI could do to transition a system like mine to the new visual update without performance loss, and right now my enjoyment of the Arma 3 is balanced on knife's edge as it is.

I figured this would be an issue and I'm glad as hell I basically saved a 1.58 build for safe keeping. I'm certainly not going to deny that AMD has issues I'm not going to defend my hardware and cry about how it should work better than it has, but this has really sealed it for me. I'm basically holding on white-knuckled to my 1.58 release and doing whatever it takes to keep it for as long as I feel the need to enjoy A3 as mine is the 980 black ed Phenom II and subject to those very diminishing performance returns. I will be building a new machine either late in the year or sometime early next year, but I'm simply not taking the kind of performance hit that I assumed I would on this recent update simply because I know damn well my hardware is too old and simply isn't worth upgrading. It's annoying that I'm having to go to such extremes to preserve A3 in an optimal state for this machine, but it appears I now have to do what I have to do. No real complaints, I know this PC is getting older, I just wish it was easier to keep A3 for my own personal use within a performance envelope which I enjoy and am happy with. I just absolutely will not accept a reduction in performance that I have previously enjoyed (framerate, drawdistance, etc) in exchange for fancier visuals, I like my 3+k draw distance, as well as a nice balanced ability to have a reasonable number of AI operating at the same time. I'm assuming if my system were just slightly less dated I would possibly not experience such diminishing performance returns in the face of the 1.61 optimization update, but I'm glad as hell I had the presence of mind to quarantine my 1.58 installation otherwise my performance and capability would have dropped beneath what I was previously enjoying and possibly into "why bother" territory.

Not a photographer, but yeah everything just looked bright and washed out to me, somebody said it looked reminiscent of OFP which I agree with. No doubt the devs will work the kinks out, and I'm sure the community will get into it and we'll see all sorts of tips and tricks from people on how to make the game look this way or that. I got my installation to scale back to 1.58, I'm running performance build 6 and I'm pretty happy with it for the time being, I don't feel like dicking around with 1.60 and trying to get it work as close to 1.58 visually and performance wise right now. I'm glad I have that option, maybe as people figure things out and possibly if an optimization build is made for 1.60 that might change for me.

It looks all the same on my machine, I noticed Stratis just seemed to have a very bright/washed out OFP'esque look to it, on top of which was the anticipated performance issues that go along with it. I'm glad there are some other people who drew the correlation to it looking like OFP, because that's exactly what I thought of when I saw it. I'm personally not a fan, I tried downgrading to 1.58 and it didn't work for me which is unfortunate, I personally think BI needs to get off the hedonic treadmill development wise. There was nothing broken about the game prior to this release, some of the screenshots of the new visuals look nice enough, and if I had a better machine I'd be interested in how it plays out, but I am skeptical of the prospects of being able to tweak the new graphics settings and have the game perform and look as it did before the update. Both visually and gameplay wise I was pretty happy with where I fell on the performance envelope. Nobody wants to be told: "You're going to have to have the game either look worse or play worse" if your system can't keep up, and to be honest it's not really justifiable either.

Do these changes only apply to individual terrains? That is to say, is it a fundamental change to how existing legacy terrains interface with Arma 3 graphically or do they have to dig into each terrain themselves and modify them? Pre 1.60 I might have guessed yes, but I have no idea now.

One major concern that I'm going to address here because it still pertains to A3 and is pretty much integral to my continuing to have any use for this game is the fact that legacy Arma islands are now mostly unplayable due to how the lighting system/sky has changed. I'd say 90% of everything I do with this game involves legacy islands. Also that being said, does anyone have any specific tips as to what to change graphically in order to regain some performance while at least maintaining some comparable level of visual quality with the previous update? Even on stratis with no other entities we're right back to the god awful loading stutter when doing something as simple as turning my view and I don't really see any considerable improvements aside from the fact that daytime terrain seems marginally brighter. All that aside, I'm very concerned for the future of being able to use legacy Arma islands with this game, making some a-priori argument about it not being a guarantee or the game not being intended for such things is a completely facile self-referential argument. Being able to use legacy terrains added a lot of replayability and if I personally as a consumer had a choice between being able to use those for which there is no "good" reason to not continue to do so, or better lighting, I'd stick with the former. That being said, I'm going to have me a downgrade and continue to use the game as I have while I can.

I was quite impressed with 1.58, I was anticipating it to be a pretty massive performance downgrade based on the issues I had been having and I was pleasantly surprised. That being said, with the most recept hotfix, the stuttering is back with a vengeance, I'm assuming it might have to do something with the memory allocator being tinkered with and supposedly "fixing" something. I never experienced the performance degradation cited for the fix, but I sure am now. I'm going to restart my computer and see if anything is wrong on my end, but this is rather disappointing, I was rather optimistic for this update and now the stuttering is back.

I have a few personal mods I've made that no longer seem to overwrite default weapon sounds, I'm not sure whether this has to do with something not entered into the cfgpatches array or some new way the sounds are handled. I have noticed SoundSetShot and the XXX_Shot_SoundShader class. Are these necessary to declare when overwriting stock weapon sounds now or is this just some kind of present bug affecting the game at the moment? I'm sorry if this issue was discussed elsewhere, but if I bring this discussion into sound mod specific forums they're likely to tell me "update my mod", and I just want to know how to fix this for my own sounds. EDIT It appears as if these entries are now part of a fundamentally different way A3 handles sounds.

Does the replacement suppressed sound for the vermin sound reminiscent of the base suppressed sound or is it not properly playing and defaulting to the base sound?

I finally had an opportunity to give this a go, I'm noticing a considerable improvement in Perf v6 over the steam release 1.58 binaries, especially with regard to script execution which is crisp and responsive, it doesn't feel as if my system is choking whenever scripts are being processed. Framerates seem fairly robust even with a good number of AI in play amid large amounts of sound and visual effects. Good stuff.

I'm not sure if this is actually happening, but it seems as if both helicopters and aircraft are subject to the bounded despawn radius. If I could make a helpful suggestion, it would be to include an option disable the despawn limit, especially for aircraft if not include a new variable that applies exclusively to aircraft to retain the option of keeping ground-level combat moving quickly whilst preventing cumbersome despawning of aircraft.

A busy night turned into a busy weekend, I had -nologs enabled when running arma so there wasn't much in the way of RPT files so I had to disable the parameter and create one, I'm sending it via pastebin along with my dxdiag, I hope that's okay as I don't know how people feel about being sent files from random people these days.

I will get those to you ASAP, I unfortunately have a social engagement I can't get out of this evening so I will do so when I can. And yes, after previous experiences I verified the game cache, no apparent failures, ran the game, experienced the performance issues, restarted it, ran it again, did so a second time. And yes, no crashing at all, I haven't experienced any crashes with 1.58 at all, including this update.