warkonaut

A new system called Dynamic Simulation has been sitting on Dev-Branch for some time. In short: it's a tool that can be used to selectively control object and unit simulation based on player and enemy presence. Due to the nature of the system, it cannot be used everywhere on everything. Some scenarios might heavily profit from Dynamic Simulation, whereas some might not be able to use it at all. The Dynamic Simulation is still in the testing and tuning stage. Its core functionality is done, along with the Eden Editor implementation. It is now being tested and tuned in real scenarios. To get more information about the system, how it works, how to set it up and how to properly use it, please refer to the documentation: HERE We would gladly welcome constructive feedback, so please read the documentation, give it a try, and share your notes. If you can provide real use-cases of Dynamic Simulation (i.e. attaching a mission where you are trying to use it), it will greatly increase the overall feedback value. Thanks, Bohemia Interactive, Team Mike

New version of Revive system was added to Steam dev-branch. BASIC FEATURES New player interaction based on (new) 'hold action' tech. New 2D and 3D visualization. Extensive control over Revive rules through mission settings and/or config. Backward compatibility. Custom made animations. Engine based unconscious state. 3 different unconscious state triggering models. Enhanced performance - low CPU load and network traffic footprint. LIMITATIONS Unconscious state and Revive works only for players, AI units cannot perform Revive nor they can be incapacitated.FUTURE PLANS Engine based unconscious state triggering. Unit animations improvements, both visual and functional. Unconscious state visualization moved to engine. Hold action tech moved to engine. Unconscious state and Revive functionality extended to all units. Please feel free to give it a try and provide a feedback. Warkonaut

Killing a friendly soldier now awards player with fixed -1000 rating.

Hi, I assume there are quite many objects and you do not want to show them later (they are being hidden and stay hidden). In such case I suggest you use local hiding.

Hi guys, an update: Hide Terrain Objects module - it is now possible to force module to operate locally, to avoid huge network load in MP scenarios where module is hiding thousands of terrain objects. I have added a checkbox that forces module to hide objects locally on each client. I tested it on Tanoa, where I was hiding more then million of terrain objects. Without this option ticked the client just didn't load, with it it is quite OK. Still takes some time, but it is fine for such large number of object. I still do not suggest to use it for hiding such great number of objects, but in general if you are going to hide more objects in MP the option is valid as the load times are shorter and the network traffic is much lower. The only drawback is that hiding happens on client join and is local - so you need to bear this in mind if you want to manipulate with the visibility and/or allow damage states during mission runtime. Have fun. :)

I would say, this module is not ideal for what you are trying to achieve. It's power is in WYSIWYG approach, so it allows you precisely select the affected area. If you want to clear whole island from objects you do not want you should probably write your own script and execute it through remoteExec on each client. Then it will work even after JIP. If you use hideObject, then the change will be only local and no extra network traffic should be created.

Hello. To be honest you are using the module for something that it was not designed for. In ideal world it should not be the issue. However the 2 environmental modules (Hide and Edit) present scripted solution, that has no engine support and so it is far from ideal. Their main purpose is to allow slight adjustments of the environment so you can tweak the terrain here and there to suit your needs, be it narrative or gameplay. Hiding all objects but vegetation from the map is far from what was the scope of the modules. Seems from what you describe the hideObjectGlobal seems to kill the network due to large amount of traffic you generate by hiding thousands of objects. I will look into the (optional) possibility of making hiding of objects local.

Hi. Not all objects work well as simple objects - some objects require adjustment data (that need to be prepared properly by the content creator), some do not work at all (like units, game logics, weapon holders etc.). Because of that objects need to be whitelisted for the simple object feature to become available in EDEN. The decision if object is suitable and well prepared for simple object feature is left on the object creator. Whitelisting is done by adding config parameter eden into SimpleObject class in object config definition. Objects without this parameter will not have the Simple Object option available in EDEN editor. Example definition: class B_LSV_01_armed_F { ... ... ... class SimpleObject { eden = 1; ... ... ... }; ... ... ... }; We tested all our assets and whitelisted all that were working fine as Simple Objects and at the same time got some measurable performance boost of it. In other words if you cannot set an object as Simple Object, you wouldn't get any performance boost of the feature (e.g. simulation house objects) or it would be horribly broken (e.g. weapon holders) or often both of those no performance boost and broken (grenade that cannot be thrown through military cargo buildings etc.). With exception of units you can still create everything by script if you for some reason insist on it. Note: I did update the object attributes with explanation that the feature is available only to objects where it works and brings some benefit: https://community.bistudio.com/wiki/Eden_Editor:_Object

Hi, check the FT. Hope it helps. Regarding the concerns about accessing and readability of the code, you can preview task related functions from Function Manager. You should get all the needed info about each function from its header.

Hi there. Thanks for the feedback. Both functions (bis_fnc_enemyTargets and bis_fnc_enemyDetected) are built on nearTargets command, which is not very performance friendly. At the time, they were created there were no commands like array select expression or array apply expression and to be honest the scripted functions were not optimized for best performance. I refactored both functions. The results are relative to test scenario so take them with grain of salt. On scenario, where there are 128 enemy targets the bis_fnc_enemyTargets now runs about 3x faster and bis_fnc_enemyDetected runs about 10x faster. We are still not happy about the performance, but both commands used in those functions (nearTargets and targetsQuery) are quite old and their functionality is tight closely to core target handling mechanics = not that easy to refactor. We are looking into our possibilities, if we could create a new command that would provide you with the same output as the bis_fnc_enemyTargets does, but would work considerably faster. Regarding the game logics and function bis_fnc_ambientAnimCombat, the function creates those logics for ambient units attaching.

The recent change to Regular difficulty preset changing Waypoints visibility to Fade out was reverted. On Regular difficulty waypoints are once again always visible, setting was set back to Show. Waypoints appearance, mechanics and both official and community content were designed around the presumption waypoints are visible on Regular. Changing that at this point would net more issues than benefits.

Dynamic Simulation doesn't handle spawning and despawning of units and objects by it's own. I suggested that if you want to create a mission with hundreds (500+) of AI units it would be wise to use some high level scripted system tailored exactly for your own needs. We cannot simply auto-delete units or objects as they get disabled, as it could interfere with custom scripts and system that are used in the missions. There is no simple generic solution that would satisfy all community needs and fit to all scenarios. By disabling simulation you should not be able to remove the object collisions, hide object does this, not enableSimulation false. If so, please create a repro and report it. Dynamic simulation manager is run on each client, as long as there are any entities registered. If there are none, it is suspended and waits for any to be added. For script commands and system to work properly unit and object locality is not an issue, but for best performance and no collisions I suggest to handle all entities and do all the dynamic simulation operations on server. Groups (resp. their units) and objects flagged for Dynamic Simulation in EDEN are added to server's dynamic simulation manager automatically.

It is sorta same as enableSimulationGlobal. It is done on the server and propagated to every client. It doesn't use hideObjectGlobal approach, as hidden objects do not have collisions and that would create a lot of issues in situations where there are objects stacked on top of each other and the bottom gets disabled by dynamic simulation. Same is true for a vehicle that would loose collision and another vehicle will park on its spot. When the vehicle would be re-enabled, the collisions would re-initiate.. To make the system works and nets some performance increase we needed to make sure, that the overhead caused by the processing of units and objects around each player will be as low as possible. Imagine you have a scenario with 400 units, 3000 of objects and 16 players. You really cannot handle this properly from script using a distance comparison method. The grid system due to its nature (being grid, resp. multi-level grid) and the fact it runs in engine on separate thread (to prevent any simulation slowdown), it allows us to process large number of units and objects lightning fast. Unfortunately we cannot add the visibility checks, they are too expensive. It would defeat the purpose of the feature where we are fighting for every split of ms. You can control the dynamic simulation from script. Try using a trigger, when the support unit enters the trigger remove the groups from the dynamic simulation system (object/group enableDynamicSimulation bool) and they will start to fight each other. Or in such case you might find you don't need to use dynamic simulation at all. Disable those units (enableSimulationGlobal) and when player or your support group enters the trigger, re-enabled the simulation. There is none. Zeus has the POWER to delete entities if needed. :) Good point. Noted. Cannot be done due to backward compatibility and the restrictive nature of the feature. All needs to behave and work by default as before. You can select multiple objects/groups in EDEN and apply the settings. The setting state is visualized on scene by the blue square next to the object icon to allow fast recognition of dynamically simulated objects from simulated or disabled objects. As stated above, Dynamic Simulation controls the simulation of objects and units in similar way as enableSimulationGlobal does. Difference is that there is almost no overhead when processing those entities, you have the settings and commands to control it and you have the interface (EDEN) to set it up. But at the end you will face the fact, that 500 units is quite a lot and even if disabled, they cost some resources. We were testing it in mission with ~800 units and found out, that Dynamic Simulation will not save the day just by itself, as the engine even if they are disabled needs to process them sometimes, check if they still should stay disabled, are valid, their position didn't change etc. and due to the large number it just eats few milliseconds. I suggest using some high-level approach that will spawn and despawn entities according to player position or mission stage, while handling the entity simulation through Dynamic Simulation. This way you can create a mission that will play well even if you use whole island and hundreds of units. It depends on the simulation type the particular object uses. E.g. objects using simulation 'house' usually do not benefit from disabled or simple simulation at all while for physx objects there is a major performance increase when disabled and even bigger when simple. If you would sort objects how performance hungry they are from the most (on right) to the least (on left): simulated > disabled > simple with class > simple without class > deleted

We would love to have virtualization of distant units/manned vehicles and simulation of their movement and combat, but it's unfortunately out of the feature's scope. Community can achieve various awesome things in their creations that perfectly fits their needs and cleverly avoid the pitfalls. And that's cool. Problem is that official complex features need to work in the sandbox, not just only in one or two specific scenarios. There must not me any core limitations and major shortcomings. To do such a core feature like unit virtualization properly, you need to implement it into the simulation system when it is being developed.

Both Dynamic Simulation and Simulation Manager module work on the same principle - according to distance to player(s) they either enable or disabled simulation on the handled subjects. Differences are: Dynamic Simulation evaluations and operation has close to 0 negative impact on performance; there are no sudden fps drops, it all runs silently on background, using a separate thread Dynamic Simulation handles all types of objects, while Simulation Manager only handles units and vehicles. Dynamic Simulation provides more control over it behavior; you can set activation distance for empty vehicles to 100m to save precious resources and still allow player to properly interact with the vehicles and at the same time have 2km activation distance for manned vehicles. Dynamic Simulation is meant to replace the scripted Simulation Manager and provide solid solution for you to improve performance on larger missions with numerous compositions and groups.

The Dynamic Simulation settings should now be available on dev (executable rev. 1.67.139561+).

Hi guys, the problem with non-accessible settings in the Performance tab was fixed. You will get the fix with the new exe that should hit the dev today or tomorrow. Thanks for the initial feedback. I will be answering your queries as well as I can in the following days (while actively working on it) - it is still being iterated on, we are doing internal testings and adjustments to it. There might and probably are some issues, so brace yourself. ;)

Hi, the EDEN settings should work for you as well as the description.ext settings. They both feed the same input to the system, so if one doesn't work for you, the other won't as well. Regarding your question about config settings, you can find all supported parameters there: https://community.bistudio.com/wiki/Arma_3_Revive#Config_settings Check the page for more info. To test you mission in MP, you definitely do not need multiple people, just run multiple instances of Arma 3. I suggest to use different profiles to avoid conflicts when accessing and updating profile data.

Thanks, I will look at it.

Can you still experience this issue?

Thanks for the info. I added support for marker to the function BIS_fnc_taskSetDestination.

Do you execute the example code from console? If so, the problem is that the function contains sleep command, but such commands (waitUntil is another example) must not be called in non-scheduled environment. If you want to run such code from console, you need to spawn it. Try instead: _handle = [0] spawn BIS_fnc_fadeEffect;

The task system core behavior remains same. Tasks are still local. Their proper functionality in MP environment is still handled by scripted functions (e.g.: bis_fnc_taskCreate, bis_fnc_taskSetState,...). The scripted framework was updated to accommodate for the new functionality and there were several changes and fixes done to prevent occasional faulty behavior. In the current version of task framework there are currently no known issues. In tasks overhaul we focused mainly on tasks UX and UI. The goal was to improve the players experience while playing and interacting with tasks. Give it a try in 1.58 and if you find any faulty behavior, please report it on http://feedback.arma3.com .

Thanks for the feedback. Tasks Overview is now using the same fadeout times as the remaining navigation and commanding elements. This is not final. We plan to improve on the feature in near future and tweak settings and behavior.

Don't worry, the Task Overview feature will stay. We will hide just the widget till it's functionality gets refined.