"X-Cam" and "DAC" Project

[SavageCDN 231]

This!

It's like cutting a Porsche and a Camaro in half and then welding the front of the Camaro on the back of the Porsche ... you could do it, but it really makes no sense. And DAC caching is doing a very decent job, at least in my humble opinion.

Haha great analogy!! ... and sorry I did not mean to say DAC caching was inferior in any way just different.

Can't wait to try it out

[ringoray 1]

DAC coming out will be the making of ArmA in my opinion. I just love big operations with lots of objectives without lag or fps issues. DAC works really well in that respect in my opinion, bring on the DAC!!!

[SavageCDN 231]

Zorrobyte has released an updated version of Group Link 4 for Arma 3:

http://forums.bistudio.com/showthread.php?175475-Group-Link-5-Core-(AI-Enhancement)

My question here is.. for Arma 2 GL4 and DAC got along quite nicely including sharing some information between AI. Do you think this would be possible for DAC for Arma 3? What would be involved to get this done?

Thanks!

[silola 1086]

Hi,

there is no direct sharing of information between DAC and GL.

However, there is still the DAC group variable called "DAC_Excluded" that can be queried.

If Zorrobyte has not changed the corresponding script code, GL should automatically

detect a DAC group when a group was released from the DAC system.

It's also possible to insert a GL controlled group into the DAC system.

Zorrobyte could search for "DAC_Excluded" within the GL script code to determine whether the code is still present.

See also DAC_Readme_Page_25 for more informations:

https://de.owncube.com/public.php?service=files&t=17606a879cb7d3490e8829e934bb0885&download

Greeting

Silola

[SavageCDN 231]

Thanks a lot for your reply Silola I'll pass on the info

[zorrobyte 30]

Hi,

there is no direct sharing of information between DAC and GL.

However, there is still the DAC group variable called "DAC_Excluded" that can be queried.

If Zorrobyte has not changed the corresponding script code, GL should automatically

detect a DAC group when a group was released from the DAC system.

It's also possible to insert a GL controlled group into the DAC system.

Zorrobyte could search for "DAC_Excluded" within the GL script code to determine whether the code is still present.

See also DAC_Readme_Page_25 for more informations:

https://de.owncube.com/public.php?service=files&t=17606a879cb7d3490e8829e934bb0885&download

Greeting

Silola

I appreciate the info! Unfortunately after doing a directory wide search of both GL4 (fresh copy downloaded from Armaholic) and GL5 (minimal changes were made from GL4), I cannot find a "DAC_Excluded" or mention of DAC in the codebase. It may be that it is named something different or works in a different way in GL5 but if missing, I wouldn't mind adding.

So that I understand, the end goal is to pass AI groups between DAC and GL so that when init by DAC, GL doesn't control group and when in GL, DAC doesn't control group? I would think that DAC and GL can play nicely together as thus far, my observations are that GL doesn't set overall waypoints but control the units directly in coordination of their waypoints, IE if DAC sets waypoint to go to another zone, etc GL allows WP until group in "Combat, Advancing, House Search" in which GL takes over but after cooldown they should proceed to their waypoints overall set by DAC.

However, I do see GL interfering with DAC units for the "Reinforcement" type as groups may be pulled out of DAC zones and into battle, this would be an improvement area in GL to play nicely in DAC as if I remember correctly, DAC has its own reinforcement type code if enabled between zones, interzone etc. I wouldn't mind finally adding the feature to GL if it truly doesn't exist (or has existed) in GL.

[silola 1086]

Hi,

I appreciate the info! Unfortunately after doing a directory wide search of both GL4 (fresh copy downloaded from Armaholic) and GL5 (minimal changes were made from GL4), I cannot find a "DAC_Excluded" or mention of DAC in the codebase. It may be that it is named something different or works in a different way in GL5 but if missing, I wouldn't mind adding.

Hmm ... that's odd, because I've assumed that GL exactly interrogates this variable to ignore "DAC" generated groups.

If I have understand the concept of GL correctly, then both, editor placed and also script generated groups are automatically detected by GL,

and then each group will be equipped with enhanced behaviour. Is that right?

To exclude DAC generated groups in this procedure, we have agreed on this variable, because otherwise both AI extensions would adversely affect each other.

So that I understand, the end goal is to pass AI groups between DAC and GL so that when init by DAC, GL doesn't control group and when in GL, DAC doesn't control group? I would think that DAC and GL can play nicely together as thus far, my observations are that GL doesn't set overall waypoints but control the units directly in coordination of their waypoints, IE if DAC sets waypoint to go to another zone, etc GL allows WP until group in "Combat, Advancing, House Search" in which GL takes over but after cooldown they should proceed to their waypoints overall set by DAC.

I think that can not be realized in this form, because DAC is not working with real waypoints, but only with generated/saved positions, which serve as waypoints and DAC used similar functions as GL, eg Houses searching, detecting/using of empty vehicles and guns, call support units, etc. In addition, DAC also affects the behavior of the units on a large scale.

I suggest that we first ensure that both Addons can be used easily with each other, and the user can decide exactly which groups are controlled by what addon.

In addition, it should always be possible (during a running mission) that certain groups can switch between the different AI systems,

and that as often the missionmaker it want/need.

These functionalities are already available and must be tested and perhaps only slightly adjusted.

However, I do see GL interfering with DAC units for the "Reinforcement" type as groups may be pulled out of DAC zones and into battle, this would be an improvement area in GL to play nicely in DAC as if I remember correctly, DAC has its own reinforcement type code if enabled between zones, interzone etc. I wouldn't mind finally adding the feature to GL if it truly doesn't exist (or has existed) in GL.

That's correct. And this is one reason, both addons should do their work autonomously, as I said before.

But maybe we can expand the cooperation between the two systems later. Who knows ;-)

Greeting

Silola

[SavageCDN 231]

Hmm ... that's odd, because I've assumed that GL exactly interrogates this variable to ignore "DAC" generated groups.

If I have understand the concept of GL correctly, then both editor placed and also script generated groups are automatically detected by GL, and then each group will be equipped with enhanced behaviour. Is that right?

That is correct as far as GL behaviour is concerned as long as the GL init module is placed in the editor. I know this works for 'GL5' as well as I've tested it already with the ALiVE mod (which generates groups like DAC does).

These functionalities are already available and must be tested and perhaps only slightly adjusted.

That's correct. And this is one reason, both addons should do their work autonomously, as I said before.

But maybe we can expand the cooperation between the two systems later. Who knows ;-)

Greeting

Silola

That would be ideal and while I'm pretty useless in the scripting/coding department I'm more than happy to test functionality between the two..... having used DAC religiously in Arma 2 and Group-Link 4 as well (both script versions but I assume things will work the same for mod versions).

[delta99 34]

I appreciate the info! Unfortunately after doing a directory wide search of both GL4 (fresh copy downloaded from Armaholic) and GL5 (minimal changes were made from GL4), I cannot find a "DAC_Excluded" or mention of DAC in the codebase. It may be that it is named something different or works in a different way in GL5 but if missing, I wouldn't mind adding.

DAC_Excluded is likely a global variable in the DAC codebase and therefore available anywhere else including GL codebase. I think this is what the other poster was referring to and I'm almost positive that is how things work.

[zorrobyte 30]

That is correct as far as GL behaviour is concerned as long as the GL init module is placed in the editor. I know this works for 'GL5' as well as I've tested it already with the ALiVE mod (which generates groups like DAC does).

That would be ideal and while I'm pretty useless in the scripting/coding department I'm more than happy to test functionality between the two..... having used DAC religiously in Arma 2 and Group-Link 4 as well (both script versions but I assume things will work the same for mod versions).

I've noticed this behavior as well, GL works great with EOS and other AI spawning and even HETMAN plays nicely.

Script version is in the same as the addon with the difference is the "userconfig" is in the mission directory. I've been busy with Lordprimate porting over the FX and dubbing features, 'GL5 Special FX edition' will include mission based init and further fixes; 'Core' version will remain AI only. Of course DAC related changes to GL codebase is welcomed for smooth operation and would take priority.

[zorrobyte 30]

Wouldn't mind setting up a repo and coordinating work, helping convert for DAC A3. I've had success with users creating tickets and it's handy to git log changes. Sent a PM.

Started tweaking for fun, here is a way to populate DAC_STRPlayers (needs work)

http://pastebin.com/d0xP90wn

Feels a bit weird having to manually set player names s1,s2 etc; method above populates pVar playerClients with all connected clients (at mission start) that are NOT HC or AI players. For bonus, also switches isHC true or false if one wanted to use DAC with HC automatically and sets headlessClients with HC if exist.

I'm banging my head against the wall to make this work for JIP as crappy cd key checking won't allow me to connect multiple clients locally. If anyone works on it, please repost here or PM.

Edited April 9, 2014 by zorrobyte

[SavageCDN 231]

^ what do you need to do proper testing?

[*tcf*jackal 10]

Im really looking forward to working with DAC again. It always gave me the granular level of control I was looking for in A2. Its exactly whats missing in A3.

Great to see you're working on it again!

[zorrobyte 30]

This is UNOFFICIAL:

https://bitbucket.org/zorrobyte/dac-a3/commits/all

I claim NO ownership to DAC and simply converted classnames/bugfixes for personal use

This is NOT for release on armaholic or otherwise.

Since many people have asked me if I will convert the DAC for Arma 3, I've recently started working on it.

But Due to time constraints I can only carry out a conversion, so that all scripts run without any errors.

Here is a great head start Silola.

*EDIT* Sorry for the language, I was slightly drunk and debugging on a Macbook Air.

[t-800a 151]

This is UNOFFICIAL:

https://bitbucket.org/zorrobyte/dac-a3/commits/all

I claim NO ownership to DAC and simply converted classnames/bugfixes for personal use

This is NOT for release on armaholic or otherwise.

Here is a great head start Silola.

*EDIT* Sorry for the language, I was slightly drunk and debugging on a Macbook Air.

This is a nice Idea, and very kind of you to set it up. BUT most of this work was already done by Silola. Be a little more patient.

The basics of DAC work fine so far, just a little bit more polishing in the more advanced stuff is needed where things in scripting have changed or we find some strange / non intended behavior.

[zorrobyte 30]

This is a nice Idea, and very kind of you to set it up. BUT most of this work was already done by Silola. Be a little more patient.

The basics of DAC work fine so far, just a little bit more polishing in the more advanced stuff is needed where things in scripting have changed or we find some strange / non intended behavior.

Agreed, if anything ends up being useful than awesome; use it/copy it/abuse it/smorgasbord. If not, then it was a fun project to keep me entertained while bored at work and furthered my knowledge of scripting.

[ringoray 1]

This is UNOFFICIAL:

https://bitbucket.org/zorrobyte/dac-a3/commits/all

I claim NO ownership to DAC and simply converted classnames/bugfixes for personal use

This is NOT for release on armaholic or otherwise.

Here is a great head start Silola.

*EDIT* Sorry for the language, I was slightly drunk and debugging on a Macbook Air.

Cheers for this Zorrobyte, this is really helpful.

[silola 1086]

Hi :-)

Thank you zorrobyte for your work, but all the listed errors/bugs are already fixed.

However, there were many many more errors/bugs in connection with Arma 3.

And I still find minor bugs, but I am very confident that I can released the DAC soon (not very soon ;)).

Provided that there are no major problems. Please be patient.

Greeting

Silola

[ringoray 1]

Hi :-)

Thank you zorrobyte for your work, but all the listed errors/bugs are already fixed.

However, there were many many more errors/bugs in connection with Arma 3.

And I still find minor bugs, but I am very confident that I can released the DAC soon (not very soon ;)).

Provided that there are no major problems. Please be patient.

Greeting

Silola

Can not wait for the official release by you Silola. DAC is the only AI script/addon that i like to use when building missions. Just wondering, will you be adding any other cool stuff to this already amazing piece of work? Although I do think it would be hard to make it any better than it already is.

[silola 1086]

Hi,

as I have already said, I work primarily at a 1:1 conversion of DAC.

But anyway I have changed some little things:

In a MP game DAC can now display a kind of progress on each client

so you can see that the DAC is working or not:

Then there's the DAC Monitor, which displays you different data in single player and multiplayer

and you can see what's going on on the battlefield:

Another small change affects the file "DAC_Config_Behaviour". You can now also enter values ​​for each sub-skill.

Old version (still applicable):

_setSkill = [0.2,0.8];

New version (alternatively applicable).

_setSkill = [[0.2,0.8],[0.4,0.8],[0.2,0.4],[0.2,0.3],[0.6,0.8],[0.4,0.8],[0.1,0.3],[0.2,0.8],[0.2,0.8],[0.2,0.8]];

I have made some major changes in the waypoint system of DAC, because sometimes the units do not move to a new waypoint, especially when a waypoint is too far away.

The DAC can now divide the route to a distant waypoint into small sections. With this functionality, I could solve the problem.

Then there's the possibility to define a master zone as a "non-waypoit-zone".

This means that the units are generated in their master zone, but will never return back to this zone.

You can see this feature in the upcoming DAC overview video.

That's all for the moment.

Greeting

Silola

[SavageCDN 231]

Then there's the possibility to define a master zone as a "non-waypoit-zone".

This means that the units are generated in their master zone, but will never return back to this zone.

Are you Santa Claus? It's like you've been reading my wishlist

[Kerc Kasha 102]

I have made some major changes in the waypoint system of DAC, because sometimes the units do not move to a new waypoint, especially when a waypoint is too far away.

The DAC can now divide the route to a distant waypoint into small sections. With this functionality, I could solve the problem.

Then there's the possibility to define a master zone as a "non-waypoit-zone".

This means that the units are generated in their master zone, but will never return back to this zone.

You can see this feature in the upcoming DAC overview video.

That's all for the moment.

Greeting

Silola

Nice that solves two of the issues I've had with DAC in the past, keep up the good work!

[*tcf*jackal 10]

+1 for the non-waypoint-zone. Excellent addition!

[ringoray 1]

Hi,

as I have already said, I work primarily at a 1:1 conversion of DAC.

But anyway I have changed some little things:

In a MP game DAC can now display a kind of progress on each client

so you can see that the DAC is working or not:

http://i.imgur.com/x2m65gE.jpg

Then there's the DAC Monitor, which displays you different data in single player and multiplayer

and you can see what's going on on the battlefield:

http://i.imgur.com/UGM6tfy.jpg

Another small change affects the file "DAC_Config_Behaviour". You can now also enter values ​​for each sub-skill.

Old version (still applicable):

_setSkill = [0.2,0.8];

New version (alternatively applicable).

_setSkill = [[0.2,0.8],[0.4,0.8],[0.2,0.4],[0.2,0.3],[0.6,0.8],[0.4,0.8],[0.1,0.3],[0.2,0.8],[0.2,0.8],[0.2,0.8]];

I have made some major changes in the waypoint system of DAC, because sometimes the units do not move to a new waypoint, especially when a waypoint is too far away.

The DAC can now divide the route to a distant waypoint into small sections. With this functionality, I could solve the problem.

Then there's the possibility to define a master zone as a "non-waypoit-zone".

This means that the units are generated in their master zone, but will never return back to this zone.

You can see this feature in the upcoming DAC overview video.

That's all for the moment.

Greeting

Silola

That sir is quite amazing work, thanks for the reply, this is going to be great!!

[silola 1086]

Hi,

the video shows all about DAC zones.

Greeting

Silola