Jump to content

Recommended Posts

I disagree. View distances should stay how they are. I want it to remain up to the mission developer to decide these things.

  • Like 1

Share this post


Link to post
Share on other sites

you haven't read and/or understood my comment.

 

i'm asking for a proper implementation of view distance settings for MP, as the "viewdistance" command is just a work-around for a missing implementation. you might know, that there are view-settings in the sever config. however they don't do anything.

but let's not hijack this thread with a view distance discussion, as i was merely interested if the dynamic simulation could be helpful for proper view distance implementation in MP...

Share this post


Link to post
Share on other sites

Make a new thread for that, it's an interesting topic and I have something to add about it too.

  • Like 1

Share this post


Link to post
Share on other sites

view distance is on client hands, depending on his video card and choice.

"discover" distance (hideObject false) should be common, scripted or edited with dynamic simulation.

Share this post


Link to post
Share on other sites
On 12/15/2016 at 5:12 AM, bad benson said:

is this going to work with agents or only with units? i assume it will but wanted to be sure.

 

It will use entities. B_soldier_F is a man class entity whether its a unit or an agent

Share this post


Link to post
Share on other sites

Well it's nice to have this "freezing" system engine based and some missions may profit from it. But I am rather disappointed as movement simulation is missing. I was hoping for an ALIVE like aproach which does at least virtual movement :(

Share this post


Link to post
Share on other sites

great system, here's some possible improvements:

 

1. detect player(in SP) or host's (in MP) max draw distance and use that to set the activation distance.

 

2. optimize the system by factoring in a player's velocity vector to try and predict which units might need to be unfrozen next. This will be useful when players are driving or flying at high speeds, not so much if they're on foot though.

 

3. allow for movement when units are frozen, and why not allow "simulated" combat to take place between inactive units.

  • Like 2

Share this post


Link to post
Share on other sites

I read through the wiki article on this, and I'm seeing the dynamic simulation checkbox in eden, etc... But I do not see the options under Attributes > Performance, yet.  I only mention this because a dev said the Eden implementation was done, and wanted to make sure I wasn't looking in the wrong spot.  To clarify, this is on main branch.

 

Sincerely hope that we can see this with 1.68, will be a major help!

  • Like 1

Share this post


Link to post
Share on other sites

can someone(anyone) post 'benchmarks' for comparison w/ current caching solutions? I think we will all benefit since we're left to empirically test by ourselves.

Share this post


Link to post
Share on other sites

Experiencing CTD when I enable dynamic simulation on a group.  The group is from a mod, rhs, so maybe that's it... however all seems to work fine until I enable this.  Submitted feedback on it, just also wanted to see if it's currently working for everyone else.  

Share this post


Link to post
Share on other sites

I can't be 100% sure, but i think there is an issue with this and a mission i been creating/testing.  Is there a way to see if a unit is affected by this?  Or disable it while in game via script console?

 

Whats happening is i was playing as a unit now twice in the mission and the unit just freezes.  I tried all the below commands with no success.  It seems to be simulation related as the unit is at a complete freeze with no blinking or anything.

 

player enableAI "all";
player enableSimulation true;
player enableSimulationglobal true;
player hideobjectglobal false;
enableDynamicSimulation false;
dynamicSimulationEnabled player;
player triggerDynamicSimulation false;

 

 

EDIT:

I guess reading a bit more this would not be enabled by default??  So this is maybe not related?  Weird...

Share this post


Link to post
Share on other sites
1 hour ago, fn_Quiksilver said:

Hey Revo, are the configs set serverside or clientside?

 

I am kinda confused, what configs do you mean?

Share this post


Link to post
Share on other sites
19 hours ago, R3vo said:

 

I am kinda confused, what configs do you mean?

 

I mean, are the scripting commands used from server or client? Are the vars global or local?

Share this post


Link to post
Share on other sites
6 hours ago, fn_Quiksilver said:

 

I mean, are the scripting commands used from server or client? Are the vars global or local?

 

If you are talking about the diag_ commands then I'd say they are local. However, I couldn't get them to work, I believe they are available only within the diag.exe, which is a shame if true.

Share this post


Link to post
Share on other sites
17 hours ago, R3vo said:

 

If you are talking about the diag_ commands then I'd say they are local. However, I couldn't get them to work, I believe they are available only within the diag.exe, which is a shame if true.

 

enableDynamicSimulation bool

 

affects all clients in the session or just the client who executed the command?

Share this post


Link to post
Share on other sites

Feature crashes A3 to desktop (on x64) as soon as you come within range of any group using it.  Provides generic access violation error.  Been doing it since x64 was released on dev.  As of yet, I am unable to get feedback from anyone else as to whether or not they are experiencing the same.  But it happens to me every time I try.  Did all the troubleshooting steps I know of, this happens only with dynamic sim, and seems to occur regardless of map, in-game situation, or mods.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, SN M. Buchanan said:

Feature crashes A3 to desktop (on x64) as soon as you come within range of any group using it.  Provides generic access violation error.  Been doing it since x64 was released on dev.  As of yet, I am unable to get feedback from anyone else as to whether or not they are experiencing the same.  But it happens to me every time I try.  Did all the troubleshooting steps I know of, this happens only with dynamic sim, and seems to occur regardless of map, in-game situation, or mods.

 

Happens to me too, here's a repro mission and the related log/dump files.

 

https://www.dropbox.com/s/ctpgs4vp1nidqua/x64_dynSimu_crash.zip?dl=0

Share this post


Link to post
Share on other sites

i think this is exactly the behaviour i described before in a post in the general discussion. kept me from using dev branch and testing it further. thx for the detailed reports on it. hopefully it gets fixed soon. can't wait to use this stuff in my current project.

Share this post


Link to post
Share on other sites
On 2. 12. 2016 at 4:40 PM, xxgetbuck123 said:

I'm guessing this is just a major improvement upon the already current 'Simulation Manage' module currently in the editor? Either looks great! 

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.

  • Like 4

Share this post


Link to post
Share on other sites
On 2. 12. 2016 at 4:51 PM, target_practice said:

I really hope an option is added to 'simulate' unit movement when disabled in the future.

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.

 

On 2. 12. 2016 at 4:51 PM, target_practice said:

Considering that numerous unofficial caching scripts have already achieved this in some way or another, surely BIS can manage this too?

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.

  • Like 2

Share this post


Link to post
Share on other sites
On 2. 12. 2016 at 5:14 PM, bad benson said:

1) is the disabling of the simulation equal to what happens using the script commands "enableSimulation" and "hideObject" or does it go deeper?

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..

 

On 2. 12. 2016 at 5:14 PM, bad benson said:

2) depending on 1) is the main benefit the grid system over a scripted solution? not saying this can be scripted but rather trying to sense how scripted it is vs engine side.

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.

 

On 2. 12. 2016 at 5:14 PM, bad benson said:

3) if distance is the only condition, will we get some type of hook to input additional ones? i was thinking that maybe in the future the system could get visibility check only checking with ray casts against the terrain mesh. i'm thinking that might be less expensive that a real full visibility check and make this very useful for hilly maps. for large even planes like deserts i think all the points under the "limitations" section would apply.

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.

 

On 3. 12. 2016 at 0:10 PM, ImperialAlex said:

Let's say I have west and east AI units fighting an ambient battle. All units are set to non-wake-up since we don't want that battle to waste resources when players aren't close enough to notice. We now allow the player to send a friendly AI support element (e.g. an armed vehicle) into that battle. We set the tank to "wake up units" since we want to allow stuff like the player sending an AI support unit ahead to clear an objective. This works as intended as long as the player is in range but as soon as he goes out of range the poor support unit is left all alone, waking up all his enemies but none of his friendlies....the poor support unit is now outgunned pretty badly. The alternative would be to keep the support unit in "non-wake-up" state, too, in which case the player wouldn't be able to use the support unit on objectives outside his current "wake up radius" which requires the player to be aware of the ranges. That just feels 'wrong', too.

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.

 

On 3. 12. 2016 at 0:10 PM, ImperialAlex said:

Oh, one more question: What's the interaction with Zeus-controlled units? Are they treated according to the underlying AI unit or are they treated as a "player"?

There is none. Zeus has the POWER to delete entities if needed. :)

 

On 3. 12. 2016 at 2:44 PM, R3vo said:

- There should be a button in the Global Settings which defaults all distances

Good point. Noted.

 

On 3. 12. 2016 at 2:44 PM, R3vo said:

- Dynamic simulation should be applied to all units by default. In most missions, there will be more objects it works for by default, than units where it needs to be disabled (At least in my missions).

Cannot be done due to backward compatibility and the restrictive nature of the feature. All needs to behave and work by default as before.

 

On 3. 12. 2016 at 2:44 PM, R3vo said:

Enabling it one by one for each object defeats the purpose and makes it tedious

- In case DS is disabled. The object attributes should be grayed out in the same way it's done with the revive attribute

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.

 

On 13. 12. 2016 at 6:20 PM, computer said:

I had a mission with ~500 units using this command with headless client and my client fps was ~ 30 with all the ai "cached".


Will dynamic simulation have a better impact than


enableSimulationGlobal

?

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.

 

On 13. 12. 2016 at 6:20 PM, computer said:

How big performance increases would there be with objects compared to simple objects ?

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

 

  • Like 8

Share this post


Link to post
Share on other sites
11 hours ago, warkonaut said:

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.

The great thing about using Dynamic Simulation is that there will be no stuttering when the unit spawns in and gets it's gear. It's great also as units can be damaged and killed while cached. So a pre-emptive artillery strike would actually have an effect.
 

11 hours ago, warkonaut said:

Difference is that there is almost no overhead when processing those entities

This is my favorite part. There's a lot of ways I've seen this done. My best result was running a single loop that checks all units. As having a loop per unit/per group would cause performance loss at higher numbers. It still only compares distance. It'd be interesting to know how the grid system works in detail. Hope it's documented. I want to know how it's done! For what I've read I take it checks the distance of the player to the cells that are populated and then either activates or deactivates units inside the cell, but how does it know if a unit is in the cell or not? How is the knowledge of a unit inside a certain cell acquired faster than the knowledge of

{if (_x distance _object < 600)exitWith{true}}count allUnits > 0


Is it perhaps an eventhandeler that fires once a cell is reached that adds the unit into the array of that cell and removes from the previous one?

 

 



In general it's a really great feature especially for less advanced mission makers, who have never cached anything before. This feature will definitely improve the average mission quality and performance. As most missions on the workshop just have all the units standing idle or patrolling constantly.
 

Share this post


Link to post
Share on other sites

_vehicle = createvehicle [classname.......];

_vehicle enableSimulationGlobal FALSE;

 

^ should that vehicle have full physx collisions with other vehicles? For some reason I am able to drive through vehicles with this simulation state as if they were inivisible, but they do take some collision damage (they get destroyed).

 

Is this how it is supposed to be, or is this a case of disabling simulation too soon after creating the vehicle?

 

 

 

Also back on topic, are the scripting commands related to DynSim server executed or client executed? Is each client running his own DynSim system or server handling for all clients?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×