DAC V2.1 (WIP) discussion

[madrussian 347]

You are the man Silola! The man! :) I love the new any-shape/any-orientation zones!

Some big requests for 2.1:

1. Removal of DAC units from the DAC system on the fly (via a function).

Recently we gained the ability to add non-DAC units to the DAC system on the fly, which was huge. What is sorely missing now imo is the reverse. This is big for a number of reasons, namely so that we as the mission designer can grab a DAC group, temporarily "unDAC" them, send them out on a mission related task, and then add them back to their zone when ready.

2. Changing the number of groups in a given DAC zone on the fly, via a function.

3. Assigning a user defined point cloud to replace all or a portion of existing DAC generated points in a zone, on the fly, via a function.

I actually wrote a set of functions achomplishing this for DAC 2.0 which work like a charm (personal use). I've also got a robust function that pulls in marker points (prep to get them into the DAC) that folks would probably find useful in conjunction. If interested Silola, let me know and maybe they can make their way into 2.1, provided they're up to your standard.

4. Destroying a DAC zone completely, and returning the groups to the system (different than #1).

Anyhow keep up the good work. You've made so much possible for all of us over the years with your DAC...

Indeed, I'm not afraid to admit I still enter a mesmerized state just watching the DAC do it's thing and personally I cannot thank you enough Silola. :)

[Aelin 10]

awesome mod but...:what is it for?:bounce3:

I did not understand anything about it:rolleyes:

[Uglyboy 10]

awesome mod but...:what is it for?:bounce3:

I did not understand anything about it:rolleyes:

It's a awesome tool for mission designers :) I'm not going to explain more because it would take an hour to make such a post :D

[scruffy 21]

Awesome!

I'm looking forward to getting my ass kicked by the AI :o

[silola 1086]

Hi :)

Some big requests for 2.1:

1. Removal of DAC units from the DAC system on the fly (via a function).

Recently we gained the ability to add non-DAC units to the DAC system on the fly, which was huge. What is sorely missing now imo is the reverse. This is big for a number of reasons, namely so that we as the mission designer can grab a DAC group, temporarily "unDAC" them, send them out on a mission related task, and then add them back to their zone when ready.

I am planning a system with which it is possible to disable the DAC-moving routines

and also the DAC-behavior routines.

If you disable the behavior routines, the DAC uses only a simple script to move the units to their dynamic routes.

This means ... at this point, external behavior scripts can be involved.

In addition, if you disable the moving routines, DAC generates in principle, only those groups and the complete control

of the units can be assumed by other external scripts.

Either the routines can be turned off completely, or they are switched to

"standby" in order to reactivate the routines at a later stage again.

2. Changing the number of groups in a given DAC zone on the fly, via a function.

Hmm... I think such a feature could be included in a future version. :)

3. Assigning a user defined point cloud to replace all or a portion of existing DAC generated points in a zone, on the fly, via a function.

I actually wrote a set of functions achomplishing this for DAC 2.0 which work like a charm (personal use). I've also got a robust function that pulls in marker points (prep to get them into the DAC) that folks would probably find useful in conjunction. If interested Silola, let me know and maybe they can make their way into 2.1, provided they're up to your standard.

If I understand you correctly, such a feature already built into the DAC.

Here is an excerpt from the readme (You did read this, right?) :p

It is possible to change the size as well as the position of a DAC zone. Such a change always causes a recreation

of new waypoints for the corresponding units from the zone.

The positions of the old waypoints are overwritten with the positions of the new generated waypoints.

This process can take several seconds depending on the amount of waypoints in the zone.

When the process is done, all groups have new waypoints then.

This function can be combined with the function "Enable / Disable" a zone.

An example: You have to deactivate a zone (all units in this zone will be deleted),

then you move the zone to a new position (if necessary you can also change the size of the zone), and then you activating the zone again.

The effect should be clear ;)

4. Destroying a DAC zone completely, and returning the groups to the system (different than #1).

... read point 1.

@Aelin

I found an old news from Mapfact, maybe it helps you a little bit to understand.

http://www.mapfact-archiv.net/include.php?path=content/download_eng.php&contentid=614&PHPKITSID=01f0aa91707e166b8fe134974b257d7a

If u need more input, read the readme...

http://www.mapfact-archiv.net/Material/ArmA/Scripts/DAC/Readme/DAC%20Readme.pdf?PHPKITSID=01f0aa91707e166b8fe134974b257d7a

And here's a little insight into the DAC behavior patterns:

thx again.

Greeting

Silola

[Aelin 10]

thank you Silola!

I am wondering if a newbie like me will be able to use it...LOL

[Uglyboy 10]

thank you Silola!

I am wondering if a newbie like me will be able to use it...LOL

Trust me it's really simple, a marker, a game logic with a line of code in the init and you are good to go :)

[madrussian 347]

I am planning a system with which it is possible to disable the DAC-moving routines

and also the DAC-behavior routines.

If you disable the behavior routines, the DAC uses only a simple script to move the units to their dynamic routes.

This means ... at this point, external behavior scripts can be involved.

In addition, if you disable the moving routines, DAC generates in principle, only those groups and the complete control

of the units can be assumed by other external scripts.

Either the routines can be turned off completely, or they are switched to

"standby" in order to reactivate the routines at a later stage again.

...

Hmm... I think such a feature could be included in a future version. :)

Awsome and awsome! :)

If I understand you correctly, such a feature already built into the DAC.

Here is an excerpt from the readme (You did read this, right?) :p

This function can be combined with the function "Enable / Disable" a zone.

An example: You have to deactivate a zone (all units in this zone will be deleted),

then you move the zone to a new position (if necessary you can also change the size of the zone), and then you activating the zone again.

The effect should be clear

What you describe above is letting the DAC pick a new set of points upon disable/enable, which I agree is a great DAC feature (and which I happen to rely on quite often). However, the function set I wrote actually does something completely different and new to DAC!

The purpose of these new functions is to replace existing DAC points with a specified number of user defined positions in an array, and most importantly, do so on the fly (i.e. w/o disable/enable and furthermore bypassing the logic/waypoints method provided inside DAC). Best of all I was able to get it working with the DAC point markers.

There are three main functions.

1. GetDACPoints.sqf

// This function returns all waypoints of a given type for a given DAC zone
// Call with [Zone, Zone_Type] call GetDACPoints
//
// Zone:      The DAC zone to retrieve waypoints from.  Can be the zone itself (trigger) or the name of the zone (string)
// Zone_Type: The type of DAC waypoints to retrieve.  One of the following: "S", "V", "T", "A", or "C"

2. ReplaceDACPoints.sqf

// This function replaces a number of waypoints in a given DAC zone
// Call with [Zone, Zone_Type, Replacement_Waypoints, Max_Replace] call ReplaceDACPoints
//
// Zone:                   The DAC zone to undergo waypoint replacement.  Can be the zone itself (trigger) or the name of the zone (string)
// Zone_Type:              The type of DAC waypoints to undergo waypoint replacement.  One of the following: "S", "V", "T", "A", or "C"
// Replacement_Waypoints:  The replacement set of waypoints (positions)
// Max_Replace (optional): Maximum number of waypoints replaced.  If used, the function will randomly select this number
//                         of waypoints from the replacement set.  If omitted, the entire replacement set is used.
//
// Requirements: This function requires the Shuffle function by toadlife (get from OFPEC Editor's Depot).
//
// Notes: It's important to know how many points are there, before replacing them.  Use the GetDACPoints function first as necessary.

3. ReadMarkers.sqf

// This function reads in information (including position) for all markers starting with a given base name, and returns an array containing this information.
// Call with Points = [base_String, Blank_Limit, Info_Requested] call ReadMarkers
//
// Base_String:    The base name of the marker.  For example, "Station" will pick up information on "Station_1", "Station_2", "Station_3", etc.
// Blank_Limit:    The number of missing input markers to ignore.  For example, assuming the markers present on the map are "WayPt_1", "WayPt_3", "WayPt_4", "WayPt_6",
//                 using a blank limit of 2 or more would return info on all four markers.  Alternately, using a blank limit of 1 would return info on the first three markers only.
// Info_Requested: The type of information requested.  Possibilities are "Pos", "Pos&Dir", "Name&Pos", or "Name&Pos&Dir".
//
// Note- The blank limit feature is intended so that you may copy and paste in markers and then delete any of the markers without worrying about gaps.  
// A blank limit of 1000 or more is therefore recommended, to eliminate such concerns.

[Note: When using ReadMarkers as prep for ReplaceDACPoints, the Info_Requested value called out in ReadMarkers should be "Pos", in order to get back an array filled with positions only.]

In my experience, using the DAC's logics/waypoints method of enableing user-defined waypoints was always kind of cumbersome, because there's that line connecting all the points, when the points themselves really aren't related to one another point-to-point. It always looked kind of "scrambled" to me. :eek:

As a quick and easy alternative, simply pasting small dot markers and then calling the new functions is very clean, intuative, and clear.

(I should probably mention though, just how nicely the logics/waypoints method appears in your new screenshots for the new arbitrary shaped zones! Now that's a great use of the lines associated with the logics/waypoints method... very informative! )

Anyhow, if you're interested in taking a look at my functions for possible inclusion in DAC 2.1 Silola, do let me know. If not, of course that's perfectly fine as well (your show after all).

btw- I am also open to sharing these with anyone who is interested on a personal use basis. :cool:

[silola 1086]

Hi,

@MadRussian:

I see that you're a DAC professional user :) And yes, I'm interested in your functions, but I am a little bit confused at the moment.

So I have 2 questions:

However, the function set I wrote actually does something completely different and new to DAC!

Can you tell me one or two examples where your functions can be used wisely?

and ...

This function replaces a number of waypoints in a given DAC zone

This makes sense only if the waypoints are replaced before the units are generated.

Example: You generate a zone with 1 group and a set of 30 waypoints.

The group gets 9-11 random waypoints. This means that there are in the zone about 20 unused waypoints.

If these waypoints then changed later, the group will not notice this action, and so it makes no sense.

But maybe I have not understood your functions correctly :rolleyes:

Greeting

Silola

[gunterlund21 10]

This is one of the most essential addons to Arm 1/2 period. Cant wait to get it again.

[madrussian 347]

I see that you're a DAC professional user :)

If I had a million years to spend delving inside this wonder you've created, rest assured, I'd still be in awe. :)

And yes, I'm interested in your functions, but I am a little bit confused at the moment.

So I have 2 questions:

Can you tell me one or two examples where your functions can be used wisely?

Certainly. The big reason I went though all the trouble of writing these functions lies on page 16 of the manual (last line in the grey box):

"Custom waypoints are lost when a zone is moved."

Simply put, I needed the ability to use my own custom points upon moving an existing zone, with was not a capability in DAC 2.0.

A bit more on my mission I was creating. I was using five overlapping DAC zones that were designed to follow and envelop the player as he moved around the map. Once the player moved far enough I would deactivate the furthest zone and move it to the new position of the pattern that the player was entering.

Custom DAC points were critical to this mission. Figuring out how to make the logic/waypoints method for custom points would have been a nightmare in this case, but more importantly, it would not have worked anyway. (i.e. due to the zones moving)

So I rolled up my sleeves and wrote up these three functions, and after many hours to my great surprise, I got it all working!

This makes sense only if the waypoints are replaced before the units are generated.

Example: You generate a zone with 1 group and a set of 30 waypoints.

The group gets 9-11 random waypoints. This means that there are in the zone about 20 unused waypoints.

If these waypoints then changed later, the group will not notice this action, and so it makes no sense.

But maybe I have not understood your functions correctly :rolleyes:

Greeting

Silola

I read and reread what you you've written here, and thought long and hard on it, and started to think that maybe I had mis-spoken earlier on having gotten it to work on-the-fly. Because what you are saying makes perfect sense. As you mention, when the groups are created, they pick a subset of all of the points of the given type for their zone.

I have not looked at the code where newly created groups pick their points from the main set, but I am assuming they store the subset of points off in a new array? Or are they storing a reference back to the main set?

In any event, here the weird thing: My ReplaceDACPoints function actually works. I have a test mission where I replace the zone's points via an action (while the zone is up, active, with groups wandering around), and here are the results:

1. The waypoint markers move to the specified positions atop my markers.

2. The group's DAC generated destination line showing where they are going redirects to my replacement points.

The only thing I can think is that the groups retain a reference to the zone's main points array.

---------------

I hope that clears most of it up. It just occurred to me also that even if the whole "Custom waypoints are lost when a zone is moved." thing gets cleared up and that's no longer an issue in 2.1, my functions could still be a great additional tool set for mission makers using the DAC for a few reasons:

1. They allow the ability to swap for custom waypoints on-the-fly while a zone is active.

2. User placed markers for custom points are a lot easier to work with than the logic/waypoints method. With user placed markers, it's simply a matter of:

a. Place initial Marker and name it

b. Copy Marker and paste away!

c. Delete any marker in the set without worrying about gaps.

d. Come back later and paste away some more! (again not worrying about gaps)

*Indeed custom points are sooooo fast this way.*

3. Once you have your user placed markers in place, it's quite clean looking as opposed to the spaghetti-mess that is the logic/waypoints method for custom points. :D (Again that's imo, and allow me to mention again that the logic/waypoints is perfect though for those new custom shaped zones... Everything there looking sweet indeed!)

Anyhow, thanks again for the DAC Silola. It's certainly revolutionized mission making in the OFP/ArmA series. Can't wait for 2.1! :cool:

Edited October 24, 2009 by MadRussian

[mattxr 9]

omg i cant belive i missed this thread!! I am exreamly happy you are making a new version for Arma2, My happy mission editing dreams have come true for Arma2

Thank you and those custom zones look awesome!

[andersson 285]

Can I ask for a parameter where you can set the groups morale? I would like to make a side, or group(s), to flee easier.

Gdmn Im going much more frequent to this forum now hoping to see DAC2.1 in completed section..

[ziiip 1]

Waht is this mod exactly? Does it spawn random units in a geometrical shape around you or what?:confused:

[andersson 285]

The geometrical shapes, zones, that are placed will be randomly populated with units within parameters that the missionmakers define. Then units will patrol the area and they do it in an intelligent way. They search houses and cooperate, they can even send arty if they have. Units can be soldiers, vehicles and choppers.

So you can as a missionmakers build a populated enemy territory, you can even build a war with two sides. Every time you play a DAC mission you never know exactly where the enemy is, nor the exact amount and type. It then deletes units not close to a player to save resources without loosing track of type and stats, when a player is close it respawn them. This way you can populate a whole island without much strain on the system.

Thats in short. Fantastic possibilities if you need, fantastic for basic use.

One more thing, its easy to implement.

For me this builds up the world I play my missions in, whatever small or big mission I do DAC makes it random and believable.

I put this as the best thing that happened to arma/arma2 all mods, addons and scripts included. No doubt.

[silola 1086]

Hi,

@ziiip

please roll back one page. There u will see two links I have posted.

If you follow these links, u will get some infos about DAC v2.0 for ArmA1.

@MadRussian

Please excuse that I have not properly understood your functions :(

But now, after your have post this detailed info, I know exactly what u mean :)

And...you are right !

My intension was that the user does not need to leave the editor to insert user-defined waypoints.

I have not looked at the code where newly created groups pick their points from the main set, but I am assuming they store the subset of points off in a new array? Or are they storing a reference back to the main set?

Here an example to make it clearer:

For each waypoint type, there is a global array that stores all the information. This array is not deleted, and looks like this:

Waypoits for infantry...

[[z1,size,type...], wp1,wp2,wp3,[z2,size,type...],wp1,wp2,wp3,wp4,[z3,size,type...],wp1,wp2,wp3.......]

There is a small marker for each zone, right in the middle of the zone (perhaps you have seen him before).

This marker is closely aligned to the north. Now, if a zone gets a new position,

then the old waypoints in the global array are replaced by the new waypoints.

When this process is completed, the marker of the zone, turned in a certain direction. This change is seen by each group.

Each group will then test whether it is affected by this change.

If yes, the group gets new waypoints.

But only from the zone which has been modified, for example from a pure waypoint zone.

If you send me your functions, I can test them and if possible, I can integrate them into the DAC - thx :)

@All

Thank you for your interest in the new DAC :)

Greeting

Silola

[ziiip 1]

Thanks guys, looking forward to it. :)

[silola 1086]

Hi :)

Can I ask for a parameter where you can set the groups morale? I would like to make a side, or group(s), to flee easier.

There are, in Config_Behaviour a value named "_setFleeing" but I must confess,

I have never really tested this parameter...LOL

But I think about an additional parameter that determines when a group is advancing or retreating, or hold the position and wait for help.

Greeting

Silola

[.kju 3240]

Maybe you got me confused, yet what about:

http://community.bistudio.com/wiki/allowFleeing

[silola 1086]

The DAC value "_setFleeing" used exactly this command, but how this affects, I have never seen. :j:

And flee and retreat, are two different things I think :rolleyes:

[dmarkwick 261]

A bit more on my mission I was creating. I was using five overlapping DAC zones that were designed to follow and envelop the player as he moved around the map. Once the player moved far enough I would deactivate the furthest zone and move it to the new position of the pattern that the player was entering.

Sounds interesting MR, do you have a public version of such a mission?

[madrussian 347]

Interesting explanations there, Silola. :)

[[z1,size,type...], wp1,wp2,wp3,[z2,size,type...],wp1,wp2,wp3,wp4,[z3,size,type...],wp1,wp2,wp3.......]

I actually remember that format quite well, as in... it was kind of a bitch parsing through all that! :D (especially with the zones being in an arbitrary order and all.)

If you send me your functions, I can test them and if possible, I can integrate them into the DAC - thx :)

I made a quick demo mission to show the functions in action:

That email you provided me a couple years back still good?

@DMarkwick

I have big ambitions for that mission (still under development). Basically you have been wrongly imprisoned in an hostile country. While being transported on a prison bus the convoy comes under friendly attack - a rescue mission by resistance forces. Unfortunately, you get knocked out when the bus flips over in all the mayhem. When you come to, it seems you are the only survivor that has not fled - the dead bodies of guards, prisoners, and resistance fighters are everywhere, but it's obvious that scores of prisoners have escaped. Your undertaking is to escape the island and there's a big twist regarding respawn. As you encounter other prisoners, they'll join up with you. So kind of like group respawn but designed to work in coop even if all but one player is killed. (I.e. There's a death cam for dead players, but they can still get back in the game if the remaining players locate more prisoners.)

Anyhow, I basically got the overlapping-moving-DAC-zones part working (with custom points), but then Arma2 came out, and of course no DAC in ArmA2 just yet. So that project on hold pending release of DAC 2.1.

If you're interested, shoot me a PM and I'll see if I can't dig up what I had so far for you. Also, curious about your upcoming missions you might be able to incorporate it in? Sounds interesting. :)

Apology for that bit of OT. Can't wait for DAC 2.1!!!

[Uglyboy 10]

I have big ambitions for that mission (still under development). Basically you have been wrongly imprisoned in an hostile country. While being transported on a prison bus the convoy comes under friendly attack - a rescue mission by resistance forces. Unfortunately, you get knocked out when the bus flips over in all the mayhem. When you come to, it seems you are the only survivor that has not fled - the dead bodies of guards, prisoners, and resistance fighters are everywhere, but it's obvious that scores of prisoners have escaped. Your undertaking is to escape the island and there's a big twist regarding respawn. As you encounter other prisoners, they'll join up with you. So kind of like group respawn but designed to work in coop even if all but one player is killed. (I.e. There's a death cam for dead players, but they can still get back in the game if the remaining players locate more prisoners.)

Anyhow, I basically got the overlapping-moving-DAC-zones part working (with custom points), but then Arma2 came out, and of course no DAC in ArmA2 just yet. So that project on hold pending release of DAC 2.1.

If you're interested, shoot me a PM and I'll see if I can't dig up what I had so far for you. Also, curious about your upcoming missions you might be able to incorporate it in? Sounds interesting. :)

Apology for that bit of OT. Can't wait for DAC 2.1!!!

I hope you can port/make this mission in arma 2 it sounds like an epic coop play :bounce3:

[silola 1086]

Hi :)

@MadMadRussian:

That email you provided me a couple years back still good?

Yep >>> silola@freenet.de

And your mission concept sounds really really good to me.

Maybe one day we can play your mission together, fight against the dac together, die together, have fun together :D

@All:

What about mixed groups, for example 1 shilka and some soldiers together on patrol ?

Greeting

Silola

[dmarkwick 261]

What about mixed groups, for example 1 shilka and some soldiers together on patrol ?

Yep that would be nice :) I wonder if it's possible to implement an attachment functionality where you can get two or more groups within one DAC call to "glue" together and follow the same patrol at the speed of the slowest element?

Also, further to my request for a negative zone, is there a possibility to prevent DAC spawning within a distance of an identified object/unit? So that for example I can have the player start within, or very near to, a DAC zone without DAC immediately seeing the player?