fn_Quiksilver

I like the new fatigue and sway, however I think it is about 10 months too late to implement it. There are some things (gameplay-restrictive elements) which are acceptable to do around game launch that are unacceptable to do 10 months after launch. That is, of course, with the goal being player-base retention. Regardless of the merits of the alterations in 1.24, or your opinion of them, the effect will be seen via slightly lower player-counts on public and also private servers. If the goal was to shed a small portion of the player-base, or at least make changes knowing that a number of players will leave ArmA 3, then 1.24 was surely a successful update! If the same dev effort expended on sway and fatigue were expended on weapon-resting, medical system, etc... The tone of this thread would be substantially different, even if in 1.24 all the community received was a status update on the dev process regarding weapon-resting and medical system, with an estimation of release in 1.26 or 1.28. It's too bad, because Virtual Arsenal is great addition to the ArmA 3 vanilla game and it's being overshadowed by the current discussion.

I think he wants to know if, as example, he sees someone building an 'iphone', is he allowed to look over that persons shoulder while building his own 'android'. Well, there are no laws against it so it just depends how much respect you have for the work of others. ie... Its up to you! :) I would suggest at the least, that if you are gaining inspiration from a source, to ensure you have credited them, even if it looks/performs substantially different. The alternative is many modders/coders could easily go the route Sa-Matra took, and make the code all but impossible for you to read.

This is certainly possible however would advise against it for 'big' missions with many players and AI. Reason is you would likely have to add an EventHandler (ie handle damage) to every single AI that you want to be covered under this medical system. That will create a very large performance drain. It is not so big a deal on players, because each players machine only has to do the constant calculations for one event handler. If its on AI, then the server CPU has to do the constant calcs for each AI.

15/07/2014 Will be doing some assessment of 2.75 code with respect to ArmA 1.24 update, to ensure 1.24 compatibility. Also will be doing some assessment to ensure the version I'm working on releasing is 1.24 compatible. Yes that is removed for upcoming version. There is a different (imo better) implementation of inventory clearance and also inventory loading and logistics.

DEV BLOG: Side missions: - They have all received another pass. Several bugs have been hunted down and killed. They've been further optimized to stop sending unnecessary network traffic and have a gentler footprint on the server CPU and also server memory cache. - The 'secure chopper' side mission has not been functioning since ArmA 1.18, due to anomalies with createVehicleArray and isFlatEmpty. Sorted. - The 'secure Intel' side missions have received another pass, not just bug hunting, but also some gameplay upgrades. This side mission is probably the most fun part to test offline in I&A :). Currently in 2.75.30, if the target spots you he tries to run away. In coming version, there is also a lookout. Finding and taking him out is imperative in order to sneak up on the target. Only other option is to lay a crafty ambush and hope for the best! Main AO: - Addressed some more spawning issues. Frequently an armored vehicle or two was being destroyed right when it spawned, as it would spawn clipping into a building or structure. What a waste! Spent some time addressing this issue. Performance: - The comprehensive cleanup code is 100% integrated. Took ages to go through the entire mission file, as each step of the way had to be tested to ensure it works. Player scripts: - Gave players a bit more choice in which scripts they run, and also added a couple performance-boosting options to the player interface terminals. Slow computer or don't like the script? Don't use it! Players will be able to pick and choose which scripts they run. - Did some performance tweaks on a couple of the player scripts. Player vehicles: - Going to apply the changes to main AO spawned vehicles, to the vehicles that spawn at base. The vehicle manager I devised is brutally simple and I accepted for first release there were going to be some anomalies (especially in the car park!!!). General: - Added a heap more parameters for server admins to fiddle with. Example: class NumberOfEnemiesInBuildings { title = "AO NUMBER OF ENEMIES IN BUILDINGS"; values[] = {0,5,10,15,20,25,30,35,40,45,50}; texts[] = {0,5,10,15,20,25,30,35,40,45,50}; default = 15; }; ... class SafeZone { // Lvl 1 = small arms, Lvl 2 = small arms and vehicles weapons, Lvl 3 = small arms,vehicle weapons and drivers title = "SPAWN SAFE-ZONE"; values[] = {0,1,2,3}; texts[] = {"OFF","LEVEL 1 PROTECTION","LEVEL 2 PROTECTION","LEVEL 3 PROTECTION"}; default = 2; }; Medical System: I *think* medical system is at 100%. Has not had another round of MP testing yet, that's a priority in the next few days.

If it feels like a Game, then it probably isn't a Simulator. The ArmA 3 platform IMO can be shaped both for gameplay and for simulation. Out of box, I'd say its packaged as a game, not a simulator, determined by what is available from the main menu.

He wants the dialog to be local for the player who joins .. That event script runs on the server when the player joins, meaning there'd have to be an existing event handler on the client and then from initplayerserver there would have to be a publicVariableClient command somewhere to make sure that client got the message. maybe easier just to run this dialog from initplayerlocal event script.

DEV BLOG: Eased off the pressure recently. Was really trying to get next version out last week, however it just wasn't meant to be. Settled into a rhythm of getting a couple tasks finished per dev session. Today, finished off (100% done) the next iteration of player gear configuration, role-based restrictions and a safe-zone around spawn area. The current safe zone works for small-arms, but did not confront the issue of vehicle-based griefing. This update will stamp most of that out, with few exceptions. There will always be methods of giving other players a hard time, but this will mitigate it to some extent. It will also perform better and have a lighter footprint on a players CPU than prior. Admins will have parameters to implement (or not) specific role-based gear restrictions, yet also have the ability to adjust these on-the-fly should circumstances arise where they are deemed more or less necessary. ... Initial MP trials last week of new medical system were positive but revealed a serious bug. Got around to dealing with it today, its sorted and ready for another MP trial. ... Spent quite a bit of time on Thurs/Fri working on the main AO, making sure everything works just right, and introducing a little more objectivity into the gameplay. Nothing drastic, as I believe the "if it ain't broke..." expression fits well here. Also worked on speeding up spawn times and improving code performance of main AO initialization process. ... In the background, have been interlacing a comprehensive cleanup system into the mission. The cyclical ones are nice now, but they don't get in the cracks and and corners of the mission. Work in this area can squeeze a few drops of free (no gameplay cost) performance out of the code. It's almost done but is quite tedious. Also found a few monitoring loops which were significantly tighter than they need to be. Loosened them up, again for performance sake. Tasks for this week: - Get medical system to 100% - Get cleanup code to 100% - Remove the 'dev scaffolding' from some parts of the mission file.

I would like to catch up with you at some point, perhaps weekend? Have done some tweaks to BTC Revive while retaining the core features (first aid/drag/carry/load/unload). It works fine. I'll be doing some final MP testing with it in a couple days, to make sure all the variables and add-actions are fine. The one thing that remained outstanding (most of these tweaks were done almost 2 months ago) was ensuring that Healers are presented with the First Aid action near a downed soldier. Re official version 0.98, I remember there was an enableSimulation issue whereby players would go into 'variable BTC_need_revive 1' and stuck in first-person with simulation false. Only recourse was Alt+F4 to desktop. Also the respawn menu was off-screen depending on resolution.

It is also a courtesy to inform the server admin(s) of the events. They can't be everywhere at all times, so they rely on players to be eyes and ears and not just stay quiet when they see stuff.

This is horrible advice :) With all the options at your disposal as Zeus, you choose to step back into a human body? The exception I have found, is when you make yourself the objective to capture. A moving target is fun and not a normal ArmA experience. So in that case, I agree you can have good effect if you are the moving objective in a mission. But, just stepping into one enemies body in order to shoot near the players? I think that is very cheap and lacking use of curator tools. From my experience (and I have quite a bit of Zeus experience on populated servers) ... * Many great points were made in first post. that guy 'gets it'. I have only two things to add, which I do not think can be disputed: 1. Whatever keeps people on the server past their bedtime, that is the right way to use Zeus. 2. What causes them to log off early, leave the server or find another server. That is the wrong way to use Zeus. Try different things. If you are 'punishing' players for making mistakes, is that causing them to stay on your server or to log off/go elsewhere? For me, the hardest part is finding good curators to add to the whitelist. Many people who begin to use Zeus let it get to their head, and use it as a toy for their personal enjoyment. When I add it to a mission, the intent is not for the enjoyment of one person, but for the enjoyment of most/all players. If the players experience is not being enhanced by the curator, then you have found a bad curator and they should be immediately removed from access. ... One other thing. Always provide players an alternative. Without a choice, you cannot gather data. Building choices into missions allows the mission developer to gather data on what is working and what isn't. If you don't allow players a way to 'avoid' Zeus, then the only way you will notice them avoiding Zeus is when they leave your server and community. I would put in a complaints system for Zeus. When adding a curator to white-list, let them know that if a certain number of complaints are received--regardless of validity--they will be removed from white-list.

Hmm strange. Only time I have heard of that issue is when the trigger is deleted. Also some cleanup scripts can do that if they are set to delete "EmptyDetector" vehicles. Can provide a .pbo I can have a look at, if it has been modified from the one in OP. Or just more info. ie which AO did not cycle, which part of the island was it in...? I have changed that code structure dramatically for next release to improve performance and versatility, but would still like to have the 2.75 series working and stable at least until ArmA 1.26.

I use it when I want something to run without the rest of the code waiting for that thread to finish. An example is a simple timer: _clock_expired = false; [] spawn { sleep 300; _clock_expired = true; }; loop = true; while {loop} do { if (_clock_expired) then { loop = false; /* CODE */}; }; Loop will run until sleep finishes and variable changes.

Okay enough with the complaints ... What would YOU like to see in a 'big' public co-op mission? I will build it :) Rattle off some ideas, criticisms of current iterations, fond memories of past coop experiences, etc ... Keep in mind, there are certain realities to accept with public missions, and public missions that are expected to be familiar/comfortable/popular.

Thanks for VAS, been using it in public coop since Beta. Imitation is the best form of flattery.

I have to ask again, are you sure the radio tower was destroyed at the time you believe the _dt wasn't working?

Add Zeus to your MP mission and there is no excuse for it being boring. The operative question then is, which mission should you add it to? IMO, that mission is one which makes a good and fun 'waiting room'.

How are you broadcasting animations? I am working on stabilizing my medical system (heavily modified BTC revive) for release, and encountering some animations that aren't being sent to other players. Any tips re getting animations to sync? example: occurring on client: player approaches field hospital player actions AI doctor player is switchMove to prone and attachTo the table (server then comes in and takes care of the doctor animations/medical variables) the switchMove is not shown to an observer, and the observer sees the player standing up until the playMove animation after detached. ---------- Post added at 17:48 ---------- Previous post was at 17:40 ---------- You need a vehicle respawn manager ... If you put a line in the Editor init field of a vehicle, it will only apply to that vehicle. If that vehicle dies, it's gone. The respawned vehicle is a new vehicle, a clone. You need something to execute on that vehicle, and perhaps also something to broadcast that code to JIP players. Two ways to do it ... The hard way is with getVariable/setVariable .. the Easy way is using BIS_fnc_MP ... something like this: on the respawned vehicle, named _veh: [[_veh,mech79_fnc_addActionVAS],nil,true] spawn BIS_fnc_MP inside mech79_fnc_addActionVAS function: _this addAction ["<t color='#ff1111'>Virtual Ammobox</t>","VAS\open.sqf"]; That is only a basic outline. It will execute that function on the target vehicle. ... The third option is a HandleDamage event handler to prevent the vehicle from being destroyed, keeping the first vehicle alive with its addAction intact.

Hey, referring to the 2.75 version in the OP: Be careful when removing the detection trigger in favor of pure enemy counter. Reason is that I&A main objective is primarily area-clearance. Enemies can stray outside the area (this is preferred in some cases). What this means is players sweeping the area may not find the last few enemies (who could be 1km from the red zone), and play will stagnate, players will get bored, and mission progression will grinde to a halt. Detection trigger allows enemies who stray outside the red zone to still be significant in combat, but insignificant with respect to clearing the red zone/completing the objective. You're also counting allUnits in that code. Keep in mind, side missions spawn units too. ... What sort of 'mission end' are you hoping for? You mean, endMission and subsequent de-briefing? If that is the case, there is nothing of the sort coded in. It's meant to be run until the server gives out ;)... That version (2.75) is quite linear structure ... ie once waitUntil {sleep 5; count list _dt < PARAMS_EnemyLeftThreshhold}; is passed, the AO will continue with de-briefing, possible defend sequence and then cleanup/recycle to next area. I suppose I should inform ... If the radio tower is not destroyed, the above line will not be read and there could be zero enemies left in the AO and it would still not complete the objective while the tower is up. waitUntil {sleep 3; !alive radioTower}; For next version I have changed the entire structure for performance reasons and content additions. waitUntil is quite a high-speed loop, much faster than is required for mission state monitoring. I have changed the structure to a while loop with a couple 'if thens'. -- DEV BLOG: Speaking of next version, I apologize to everyone for setting a date for release ... I can't guarantee a day, but am working hard to get it out soon. The task was quite substantial and its almost over. Yesterday finished building a fully functional field hospital which is compatible with my modified BTC Revive. Today, got some work done on some more complex work with the FOBs. example: when players capture and secure the FOB, drive the medical truck to the FOB it will activate the respawn point (forward-deployed fully-functional field hospital for FOBs coming in a couple weeks). the task I was working on today is, when the enemy retakes the FOB (which is more than likely to happen many times), the respawn point is removed, and I had to put in a way for players to re-activate the spawn point when it is safe, without repeating the initial logistics mission. Yesterday, spent time working on more FOB logistics missions, specifically re-supply. Loading/unloading ammo crates that players can take to the bases to keep them supplied. I have already added a 'supply' logistics mission, but the concept of re-supply came up and I decided to add another taste of logistics and support tasking. What is still not quite up to snuff for release: - Medical system: A couple inconsistencies with acquiring the First Aid action, and duplicating actions. This is a very stripped down, leaned out and 'high-speed' modification of BTC Revive. The work on this was done 8 weeks ago, so I have to go through and revise to find where the error is. There are some setVariables and getVariables need to be debugged. Incidentally, the field hospital is more consistent with BTC revive than medics are :). - Testing the full mission cycle, testing how it transitions from region to region, how the FOBs pack up and then re-deploy when necessary. I am reasonably optimistic here, but nothing is 'done' until its tested 100 times. - Notifications and Hints. There is quite a bit of new mission content and I haven't had time to build in notifications and hints. Initial implementation will be basic. - Mission cleanup. A couple of the missions are stubborn and the units/vehicles refuse to be cleaned up. It will take an hour or two to sort this out and test it. - Some of the cleanup code is quite stiff as well, cleaning stuff up almost right after the objective is completed or the thing is destroyed. That is something that will require a second pass for following version, to 'smooth' the edges. - A lot of last week was spent restructuring the way players interact with mission features, and building/testing a vehicle respawn script. The result will be -- without exaggeration -- a 100% increase in performance and perhaps 500% (or more) increase in mission longevity .. - To understand how such a performance increase is possible, remember that ArmA 3 does not make good use of lateral processing power. By shaping mission/script structure to be 'in-series' rather than 'in-parallel', adapts better to ArmA 3's use of CPU. A 'one thing at a time' approach. Result = better performance which can go to either pure FPS gain, more enemies/mission content, or a blend of both. Last week, I converted the coming version from doing about 50-60 things in parallel to doing about 7-8 things in parallel. This frees up an immense amount of processing power (which allows AI to act smarter) and widens the performance bottleneck, giving players a little higher FPS too. - I've stopped working on scripts, and just trying to stabilize mission content for release. Work on the player/server support scripts will continue, but some have been marked as WIP and put on back burner until after this version has been run on populated server for abit. An example of this is vehicle sling. It is unstable in its current form and no time to spend stabilizing/testing it, so it is shelved for the time being. Another is squad user interface. No time! I can't put a day on it, but--assuming all is working well--it could be any day now for first public dev build of it. I tried to get it up on a server today, but testing of new format urban missions reveal the enemies are not being cleaned up when the objective is done. This is unacceptable to me. When I open the mission folder tomorrow, I have to finish off that, and then finish off the above-mentioned thing with forward respawn point adding/removing/adding. To finish off and fully stabilize the new medical system, will require some MP testing, so when i launch open dev build, that is a priority task.

Hey I like how this script is coming along! One concern i have is the use of bis_fnc_mp persistent. review your use of BIS_fnc_MP and decide whether what you are broadcasting at that time, needs to be broadcasted to players joining the game 10 minutes/2 hours/etc later. example: [[_rescuer, "DeadState"], "G_fnc_switchMove", true, true] spawn BIS_fnc_MP; If that occurred 40 minutes into runtime, could a player who joins 200 minutes (160 mins later) into runtime need to be aware that at 40 mins, something happened to _rescuer? If no, then reconsider the persistence of the bis_fnc_mp spawn https://community.bistudio.com/wiki/BIS_fnc_MP id suggest changing what is appropriate to [params,functionName,true,false] spawn bis_fnc_mp;

Just wanted to say thanks! Using your buildingPos script. Wondering if there is a later version. running this one: SHK_buildingpos.sqf Shuko of LDD Kyllikki (kyllikki.fi) IRC: shuko @ quakenet Version: 0.12

HOTFIX for ArmA 1.22 Update: Original post has been updated with hotfixed 2.75 version. Fixes: - addActions on VAS, side missions, base functionality, etc. - Cleanup code slightly improved (applied to manual cleanup cycle, on laptop in control tower). Some code from next comprehensive release was pasted into this version to address some cleanup leaks that crept in in ArmA 1.20 update. ------ Multiplayer stabilization and testing for next comprehensive release began yesterday

edit: see my next post (#34)

This script doesn't take care of rearming cargo. fuelCargo ammoCargo repairCargo used by some of the HEMTTs and the CRV-6e, and their AAF/CSAT counterparts.

Heading out of town for a few days. I'll check it out. Have done a little work on VAS but it still needs another pass before release. At one point I had swapped out to the latest version of VAS, however that version sorted lists alphabetically and there was no (that I could see) sort-by-type option. Alphabetical list sorting IMO is horrible. A rangefinder should appear beside binoculars and laser designator, not beside suppressors and t-shirts. JMO. Left on the to-do list: - Urban mission re-dress - Some systems work to support mission enhancements (custom scripts/functions) - Vehicle respawn optimizations (will net a reasonable and noticeable FPS gain) - communications optimizations and improvements (re server communicating with players). Already ripped out much of the current system, ready to add in new one. --- The version in the original post works fine, however since ArmA 1.20 has had some instabilities and performance leaks that were not present in ArmA 1.18. Nothing serious in the gameplay sense, but a serious concern from mission designer sense. As such am doing my best to get next version out. A couple tasks have been pushed off the back end of the schedule as a result. An example is building a squad management interface, simply no time for it yet. Maybe with another two weeks, but that is too long. Another is 'scaling' difficulty to match the skill/resources of the players. That is coming, but has been pushed back to a later version. sneak peek of some tidbits in this coming version: these are not central pillars, but 'nice to have' things IMO. - Artillery in the form of M4 Scorcher is returning to the mission. :) There is a system in place to mitigate and prevent abuse and over-use of it, however. - Vehicle Towing will be in this coming release. Not wholesale and it will be role-based, for certain specialist roles only. - Para-jumping will be in as well, but only for certain roles and only under certain conditions. - UAV Terminal also returning to the VAS box, but will only be usable by the UAV Operator. This will allow UAV Operator to use the VAS functionality without losing the Terminal. I'll endeavor to make the above parameterised so server admins can choose to run the integrated scripts or third-party ones.