Dynamic-AI-Creator (DAC) V3.0 released

[dmarkwick 261]

Wonderful great to see this finally released I've been dying to get my hands on it XD

The only issue I'm having though is with Trigger/Spawn zones, there doesn't appear to be anyway to set an activation zone that is larger than the spawn area, so as soon as I enter a trigger zone enemies can popup right in front of me. Ideally I would like enemies to spawn out of sight inside town areas as the players approach.

Is there anyway to have say a larger activation trigger area for a smaller actual spawn zone? Did I just miss a section in the readme/configs?

You could use one sized trigger to activate another zone, just transfer the initialisation line to the larger trigger. Or set the "active" parameter to 0 to activate a previously inactive zone.

Or, use waypoints to define the area of AI spawn. You can make a shape the exact shape of the town, see the DAC readme for further details.

[silola 1086]

Hello :)

Where can I change the value of the ai´s max. requesting distance for backup?

There are four different global settings related to ground support, which I have

unfortunately not described ... sorry :rolleyes:

The standard settings are:

1. DAC_Radio_Dist = "((1000 * DAC_AI_Level) * _skillgroup)";

2. DAC_Alert_Dist = "(100 + (100 * DAC_AI_Level))";

3. DAC_Radio_Time = "((15 / DAC_AI_Level) / ((skill (leader _group)) + 0.1))"

4. DAC_Radio_Count = "DAC_AI_Level"

1. The "DAC_Radio_Dist" is the max range in which a group leader can reach groups for support (that what you mean).

Example: If u play your mission with DAC_AI_Level 3 and the average strength of the group (the group wich requesting support)

is 0.6 then the value for the "DAC_Radio_Dist" is: ((1000 * 3) * 0.6) = 1.800m

2. The "DAC_Alert_Dist" is the maximum distance, in which the groups provide support, without they being called for support.

3. The "Radio Time" is the time interval in which a leader tries to reach a group for ground support (sending a radio message).

The calculation with the above values would be: ((15 / 3) / (0.6 + 0.1)) = ~ 7 sec.

That means, the group leader will send each 7 sec. a support request to another DAC-group, within the "DAC_Radio_Dist", but nor each request is a hit ;-)

4. The "DAC_Radio_Count" specifies the maximum number of support groups that each group leader can request.

Maybe it's better to reduce this value (example): DAC_Radio_Count = "(DAC_AI_Level / 2)"

If u want to change one of the settings, write the new code into the init line of the DAC-logic, for example:

DAC_Radio_Dist = "((500 * DAC_AI_Level) * _skillgroup)";

Greeting

Silola

[dmarkwick 261]

small question:

Where can I change the value of the ai´s max. requesting distance for backup?

I can't quite remember, but I believe the distance is proportional to the skill of the DAC AI. Silola will no doubt make it clear :)

*edit*

There you go, Silola makes it clear :D

Btw small report on my experience so far: I´ve had the most immersive firefight ever in A2 just now with AI+DAC.

I was traveling with a 3 truck convoy full of marines through enemy territory. The last truck in the row fell back (due to ai driving skills -.-). Well to their bad, a russian patrol located them and engaged them while calling for backup. The backup came from our front direction and ran into the 2 other trucks including myself.

So that was the situation: 1 truck fallen behind and cut off from us, 2 trucks furhter ahead against an APC and several infantry groups. As I´ve also put some respawn camps nearby the AI kept respawning and calling for reinforcements and finally completely surrounded us in a small village. The fight went over approx. 30 minutes. It was just so much fun fighting wave after wave :D

Well in the end they pwned us all... :rolleyes:

LOL, yeah the DAC dynamic makes missions play out differently every time. Welcome to user missions where even the author cannot say what's going to happen & when :)

[PacUK 1]

Thanks DMarkwick, figured something like that might work, seems to be working cheers!

[Skelotec 10]

:confused2: ....But what exactly must i do, to juse GL4 ? (think i dont get it!?)

Edited June 3, 2010 by Hptm.Steiner
only seperat the question

[andersson 285]

Edit: I missed to have the triggers 'Actviation' to 'GameLogic'. Works as a charm now :D But some more info about the 5 directions would be nice.

Hi, I cant do the same as you did in #D_08_DAC_user_waypoints_2.utes.

The zone spawns my 3 choppers but they are not placed at the position of the 3 waypoints I placed (for a gamelogic with 'this setdir 4').

I also tried to change the 'D'-value to '1' as you had in your example.

I have a trigger covering the area where the gamelogic and its waypoints are.

This is the trigger: 'us_h_1_n=["us_h_1",[100,0,1],[],[],[],[3,1,3],[1,1,1,1]] spawn DAC_Zone'

I couldnt find much information about what different values of 'D' can do. Also the documentation doesnt say much about what the 'this setdir 1-5' really do on a gamelogic.

Any additional information would be appreciated :)

Edited June 2, 2010 by andersson

[PacUK 1]

I'm using DAC to finish up a mission for Invasion 1944 mod for ARMA2, so far I have the spawn areas working fine (thanks for the help there guys) but am noticing some wierd behaviour in spawned vehicles.

I've used the 'wheeled vehicles' list for light armour vehicles (halftracks, armoured cars) but for some reason certain vehicles don't get a full crew compliment often only a driver present (no gunners or cargo position troops) and sometimes crew members dismount immediately from the vehicle before its even taken damage.

Is this an issue from using a custom unit, or a limitation of the wheeled vehicle unit list? All the tanks in the 'tracked vehicles' seem to get a full crew compliment so it seems odd that wheeled ones don't. I could place them into the tracked list as a last resort but this then causes problems with what units are spawned with halftracks spawning instead of tiger tanks etc.

Any advice would be great!

[silola 1086]

Hi :)

I couldnt find much information about what different values of 'D' can do. Also the documentation doesnt say much about what the 'this setdir 1-5' really do on a gamelogic.

When I read the pages 12 + 14 of the Readme, I learn everything I need to know about "setdir a logic" ;)

Question:

If I release a script version of the DAC, should I open an extra thread for it, or should I enter any information in this thread? What do you think ?

Greeting

Silola

[Two Dogs 12]

PBO vs. Script version is a tough question. The 506th server will be running the PBO version privately during drills.

We tried the script version publicly in ArmA1 and it worked until JIPs started sucking up server resources halfway through the mission.

The PBO version seems to be the way to go, and the not so tech literate, will see their their getting kicked for not having DAC. And they'll look it up and find out what it is. Its how things work.

Great Work, I've been looking forward to this for some time.

Thanks

[mcpxxl 2]

For me there is absolutly no need to discuss of merging CBA DAC

--> Take it or leave it

Sorry

[dmarkwick 261]

I'm using DAC to finish up a mission for Invasion 1944 mod for ARMA2, so far I have the spawn areas working fine (thanks for the help there guys) but am noticing some wierd behaviour in spawned vehicles.

I've used the 'wheeled vehicles' list for light armour vehicles (halftracks, armoured cars) but for some reason certain vehicles don't get a full crew compliment often only a driver present (no gunners or cargo position troops) and sometimes crew members dismount immediately from the vehicle before its even taken damage.

Is this an issue from using a custom unit, or a limitation of the wheeled vehicle unit list? All the tanks in the 'tracked vehicles' seem to get a full crew compliment so it seems odd that wheeled ones don't. I could place them into the tracked list as a last resort but this then causes problems with what units are spawned with halftracks spawning instead of tiger tanks etc.

Any advice would be great!

I think it's a problem of group size, even though you may have specified a high group size (size 4 say) you could still spawn a small group, as the config DAC_AI_Count_Level in DAC_Config_Creator.sqf) for size 4 is [2,12], which means that the group could be as large as 12, but as small as just 2.

(I believe I'm right in thinking that as many un-armoured vehicles are spawned that is necessary to transport the group size, not that the group size means how many un-armoured vehicles are spawned.)

To force a larger minimum size, either change these values or add new ones (size 6, 7 etc) and use values like [8,12] to force a higher average. As an example, I change my own config to something like:

[[2,4],[3,6],[5,8],[8,12],[10,20]]

Which guarantees a general increase in minimum size for each size increase.

---------- Post added at 06:28 PM ---------- Previous post was at 06:22 PM ----------

Question:

If I release a script version of the DAC, should I open an extra thread for it, or should I enter any information in this thread? What do you think ?

Greeting

Silola

Hmm, I should say use the same thread, separate the pbo release details from the script release details in the first post. After all, it's the same product with exactly the same functionality yes? In that case all questions should be answered in the same thread or you'll have the prospect of answering the same questions in both threads :)

That way, the only issue will be the different implementations of each, which is a smaller problem ;)

[Nephris1 10]

If I release a script version of the DAC, should I open an extra thread for it, or should I enter any information in this thread?

Open a new one plz.

Support weill be different and u can spare questions like "... did u use the scripted or the pbo version".

[andersson 285]

Hi :)

When I read the pages 12 + 14 of the Readme, I learn everything I need to know about "setdir a logic" ;)

Question:

If I release a script version of the DAC, should I open an extra thread for it, or should I enter any information in this thread? What do you think ?

Greeting

Silola

LOL, how could I miss that?? Thank you :p

I think you should release the scripted version in this thread. Its the same scripts and its easier to find the answer in one thread than two (and easier for you to answer).

[silola 1086]

I think you should release the scripted version in this thread. Its the same scripts and its easier to find the answer in one thread than two (and easier for you to answer).

That's right, I think this is a good reason to release all infos about DAC in this thread. THX :)

Silola

[xeno 234]

For me there is absolutly no need to discuss of merging CBA DAC

--> Take it or leave it

;)

Xeno

[mattxr 9]

;)

Xeno

People didnt mean merge it.. they ment just place the Pbos into the CBA mod folder so it got distributed around so more missions and servers would be able to use it.

@Soila great your making a script pack version.. will make more widely used, And yeh better to keep it in this thead :)

[Skelotec 10]

:confused2: ....But what exactly must i do, to juse GL4 ? (think i dont get it!?)

"Das setzt aber voraus, dass der entsprechende Parameter in GL4 gesetzt ist."

WO? wo nur? Ich finde den Parameter in GL4 nicht:confused::mad:

[PacUK 1]

Ahhh yeah that makes sense DMarkwick thanks for the tip, I'll try setting up some special group sizes for these units and see if it helps!

[oktane 0]

... and the thought that every mission of the 33-part demo contains the whole script package, has prevented me from a script version (about 150 mb). :p

You could have a prep batch file that a person could run if they wanted to watch the demos. It would copy the base dac code over to each demo folder. Or just zip the demo's up separate, the compression should get rid of the redundant data and make it very small. :)

Xeno's comments on new players not knowing what DAC is are very true and important for public play. When a cool addon comes out, I always try to see if it can be script based for inclusion with a mission precisely to avoid the pitfalls he refers to. Mando Missiles is a good example of something that adds a whole new dimension without requiring an addon.

Coyle, the implementation is no different. One does not have better resource management than another, DAC is pure scripts, the addon just adds the simple logic markers which init's the scripts. I think you are noticing a difference because in the case of forcing the addon, much less people were able to join and therefore you had less issues with the jip stuff. :)

If CBA wasn't going to Include DAC, prehaps the CBA team could do a favor and just include some special markers which were resizable, A generic version of what is in the DAC's config.bin. This is just to help the mission makers place their zones?

Much respect Silola, cheers!

Edited June 2, 2010 by oktane

[Razor91 17]

The DAC_Sounds signature doesn´t work.

Fix it pls:)

Edited June 2, 2010 by Bier AIG Razor

[Fox '09 14]

it runs pretty bad for me on single player. Multi.. should be fine.. but just throwing that out there. Same issues for anyone else?

[silola 1086]

Hi :)

I think I will release the script variant without any demo missions,

because it would create too much work. Only one example mission,

to see how it works.

But there is another problem ...

MadRussian has built in a few custom functions into the DAC.

These functions require new types of "Locations", which are defined in the config.

For each DAC zone such a "Location" is generated, which will be needed by the functions.

I have no idea how this problem could be solved. Perhaps MadRussian has an idea.

The DAC_Sounds signature doesn´t work.

Not? Have you (and all other players) really replaced the old DAC_sounds by the new one?

I have repacked the "DAC_Sounds" data with a new generated key.

The same procedure as with DAC_Source.

Is there anyone else with the same problem?

it runs pretty bad for me on single player. Multi.. should be fine.. but just throwing that out there. Same issues for anyone else?

What about with the demo missions? They also have a bad performance?

What units (typeof) and how much groups you generate with the DAC?

First ... switch to standard units and look how it works.

Maybe you generate add-on units that require a lot of performance?

Until now we had no major performance problems.

DAC works when proper addons are used, really well (SP + MP).

Greeting

Silola

[mattxr 9]

Hi :)

I think I will release the script variant without any demo missions,

because it would create too much work. Only one example mission,

to see how it works.

But there is another problem ...

MadRussian has built in a few custom functions into the DAC.

These functions require new types of "Locations", which are defined in the config.

For each DAC zone such a "Location" is generated, which will be needed by the functions.

I have no idea how this problem could be solved. Perhaps MadRussian has an idea.

Can you not generate the locations via script?

[madrussian 347]

I think I will release the script variant without any demo missions,

because it would create too much work. Only one example mission,

to see how it works.

But there is another problem ...

MadRussian has built in a few custom functions into the DAC.

These functions require new types of "Locations", which are defined in the config.

For each DAC zone such a "Location" is generated, which will be needed by the functions.

I have no idea how this problem could be solved. Perhaps MadRussian has an idea.

Good call Silola. :)

I just thought of this same thing a few minutes ago while catching up a few posts back. Just so we're all on the same page, the config stuff I needed looks like this:

class CfgLocationTypes
{
class DAC_Zone
{
	name = $STR_NAME;
	drawStyle = "name";
	texture = "";
	color[] = {0, 0, 0, 1};
	size = 0;
	font = "TahomaB";
	textSize = 0.04;
	shadow = 1;
};
class DAC_Point_Soldier : DAC_Zone {};
class DAC_Point_Vehicle : DAC_Zone {};
class DAC_Point_Tank : DAC_Zone {};
class DAC_Point_Air : DAC_Zone {};
class DAC_Point_Camp : DAC_Zone {};
class DAC_Utility : DAC_Zone {};
class DAC_Utility2 : DAC_Zone {};
class DAC_Utility3 : DAC_Zone {};
class DAC_Utility4 : DAC_Zone {};
class DAC_Utility5 : DAC_Zone {};
class DAC_Utility6 : DAC_Zone {};
class DAC_Utility7 : DAC_Zone {};
class DAC_Utility8 : DAC_Zone {};
class DAC_Utility9 : DAC_Zone {};
class DAC_Utility10 : DAC_Zone {};
};

Needing these locations types for my functions, I worked in concert with Silola, who added code to create these locations every time a DAC zone is created (and updated every time an existing DAC zone is updated). Then my functions detect these locations and go from there.

So why not use one of the location types provided in default ArmA2? (i.e. "Name", "NameCity", "RockArea", etc?) Good question. Here's why:

To cut to the chase, my functions require that the only locations of these types present were created by the DAC. If I were to use the existing provided locations, there would be absolutely no way to be sure that someone else (i.e. someone else's addon) didn't create them. This cannot be understated.

Thus the reason for these "DAC specific" locations.

So what can we do at this point to achieve a DAC script-only version? Well, one solution would be to just create a small PBO with only the locations? I'm guessing some are thinking that will defeat the point entirely? :p

Here's a real possible solution:

Maybe take this very small "DAC Locations" part of the config and have it exist both in:

1. The PBO version of the DAC and

2. CBA (newly added there)

That way the DAC PBO version can remain standalone, and DAC Script version takes on CBA as a requirement. If all parties are agreeable, of course. :)

Finally the same identical "DAC Locations" data in both places (DAC PBO and CBA) shouldn't hurt anything.

btw- Thanks for creating CBA. Despite what I said earlier in jest about "maybe we should be incorporating CBA into the DAC hahaha", I do use CBA all the time. Very handy stuff indeed. :D

EDIT:

I just thought of one concern regarding adding the "DAC Locations" config portion to CBA. We'd need a big fat disclaimer (in CBA docs) that states something like:

"These location types are used internally by the DAC. To avoid potential conflicts, do not create any instances of DAC locations unless:

1. You are the mission designer

2. You know what you are doing

Detecting them once DAC creates them is obviously fine."

btw- The ten DAC_Utility location types are actually meant to be used by the mission designer.

Edited June 3, 2010 by MadRussian

[xeno 234]

Hm, I just want to have the best for all players, beeing it for those who have no problems using addons and those who don't know about addons (and I don't care at all about myself, only for the those who still play online).

Seems no matter what you do some people simply don't get the idea why the situation is how it is (and I'm not talking about you Silola as I'm quite happy that you are still around and contribute to this community).

Bailing out of this thread.

Xeno