Mapfact's Dynamic AI Creator: Preview

[silola 1086]

hi,

the movement dynamic for all groups looks like this:

for example, there is 1 zone with 50 generated waypoints and you create 5 infantry groups

from which each group is to get 5 waypoints from the pool of 50 waypoints.

at the start of the mission, each group will be placed randomly at one of its waypoints.

now, there are 5 values to set randomly and every time each group reached one of his waypoints:

waypoints = ["wp9","wp21","wp23","wp37","wp44"]

combatmode = ["green","white"]

behaviour = ["careless","safe","aware"]

speed = ["limited","normal","full"]

formation = ["line","vee","column","wedge","stag column","ech left","ech right"]

the first instruction for one group looks like this for example:

waypoints = ["wp21"]

combatmode = ["white"]

behaviour = ["careless"]

speed = ["normal"]

formation = ["column"]

the next one looks like this:

waypoints = ["wp44"]

combatmode = ["white"]

behaviour = ["safe"]

speed = ["limited"]

formation = ["line"]

and so on ...

and yes, if the behaviour = "careless" the group will use roads if its possible.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">good thought, it would be interesting for vehicle convoys/patrols to have an option for "only waypoints on roads"

thats really a good idea, i will test it ;-)

bye

silola

[honchoblack 2]

Quote[/b] ]thats really a good idea, i will test it ;-)

Great news, Keep up the good work

[mattxr 9]

yes it sounds really interesting also.. when u said

Quote[/b] ]waypoints = ["wp21"]

combatmode = ["white"]

behaviour = ["careless"]

speed = ["normal"]

formation = ["column"]

the next one looks like this:

waypoints = ["wp44"]

combatmode = ["white"]

behaviour = ["safe"]

speed = ["limited"]

formation = ["line"]

will we have to confiqure every waypoint becuase that would take a while.. or is it if you just configure the first waypoint all the rest will be the same.. untill u change the next waypoint u need changed..

[honchoblack 2]

Quote[/b] ]will we have to confiqure every waypoint becuase that would take a while..

As far as I understood it, that is the dynamic part, the selections are take from a waypoint, unit, speed and formation-pool, selecting the components dynamicly for each waypoint

Quote[/b] ]is it if you just configure the first waypoint all the rest will be the same.. untill u change the next waypoint u need changed..

I think this is needed too, since the mission designer needs to have control over the different unit behaviour (eg. keep a convoy group in slow, save and colum formation, and an infantry group with changing formations/behaviour/speed)

[raedor 8]

yes it sounds really interesting also.. when u said

Quote[/b] ]waypoints = ["wp21"]

combatmode = ["white"]

behaviour = ["careless"]

speed = ["normal"]

formation = ["column"]

the next one looks like this:

waypoints = ["wp44"]

combatmode = ["white"]

behaviour = ["safe"]

speed = ["limited"]

formation = ["line"]

will we have to confiqure every waypoint becuase that would take a while.. or is it if you just configure the first waypoint all the rest will be the same.. untill u change the next waypoint u need changed..

this isn't to be defined (OFP2: TBD erm...) by the mission maker, this is the "dynamic" part. they switch to combat automatically when attacked (hm... not when they are "careless", but that's the job of GLII or something), you can't affect the behaviour as mission maker, it is all dynamical. that's how i understood it.

we should wait for Silola.

[honchoblack 2]

Quote[/b] ] you can't affect the behaviour as mission maker, it is all dynamical. that's how i understood it.

Even if the manipulation of the behaviour of the units is not supported, the mission maker could still make use of the dynamic waypoint engine, letting him use other groups with the system, which he can then influence

[mattxr 9]

i think ill post my 1000th post here becuase this thred is special..

Ok From the way i see it u just add the Zones into the map, set up in the way u want them then add a few objective's few obstacles/defences then there you go, you have your mission..

[silola 1086]

hi,

The behavior is only influenced, actually when enemys are sighted.

Otherwise the 3 behavioural kinds (careless, aware, safe) only there, not always to have the identical movement form.

A certain behavioural kind individually for everybody zone, was

not planned.

But I think that was very helpful if that was adjustable.

Especially with thus thinks like konvois.

then I will probably catch up that ;-)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">will we have to confiqure every waypoint becuase that would take a while.. or is it if you just configure the first waypoint all the rest will be the same.. untill u change the next waypoint u need changed..

hehe no. this would be one step to the back.

I might generate with little expenditure, a lot of dynamic.

if u want, i can tell u a little bit more about the configuration of a zone.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Ok From the way i see it u just add the Zones into the map, set up in the way u want them then add a few objective's few obstacles/defences then there you go, you have your mission..

for a simple mission that's ok. but we all know ... a good mission needs essentially more ;-)

bye

silola

[Blanco 0]

If one waypoint is generated on the left bank of a river and another is on the right bank, do they use bridges?

[honchoblack 2]

Quote[/b] ]if u want, i can tell u a little bit more about the configuration of a zone.

Certainly, I am very interested on your approach on zone/object detection

[deanosbeano 0]

will we be able to create dummy groups ,like in spawn manager ?

these dummy groups stop the massive lag spike when the groups spawn.

just a thought. actuall new to ai generators, but my mate taught me how to create eastdummygroup = group this.whilst using spawnmanager and the lag spikes dissapeared.

[silola 1086]

hi,

how you know, my English is not especially good. I hope you can read this.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If one waypoint is generated on the left bank of a river and another is on the right bank, do they use bridges?

Today I have begun a test on Nogova.

I have placed a main zone on the left from the bridge, a waypoint zone to the right of the bridge.

Here the result...

Then in other direction there are problems, vehicles get stuck in the bridge.

But this is probably known.

DAC breaks no limits of OFP.

If there is a problem with cross over bridges, then there are these problems also with DAC.

However, DAC contains another check...

Should an Unit from any reason not be able to reach one of her waypoints,

then the Unit will try after a certain time to reach another waypoint.

An example: a group gets 5 wp assigned. One wp is on

an island. Sometime the Unit will have this wp as a purpose.

The order "move" causes nothing at this moment. The Unit simply stops.

DAC checks every time whether the Unit has started to move. Always 10 seconds

after a Move order this check is initiated.

There is a problem only if the group gets exactly this Way Point as a start position.

The Unit would be a static Unit at this moment;-)

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">will we be able to create dummy groups ,like in spawn manager ?

these dummy groups stop the massive lag spike when the groups spawn.

The Spawn manager is a great AI-Addon. However, there are some differences to DAC.

In relation to the dummy groups I must say that it is only possible with the SpawnManager,

to use a single Unit-Addon. In this connection it does sense to generate this dummy groups.

With DAC it is possible to use many Unit Addons. This would signify,

the fact that accordingly many dummy groups would have to be generated.

This signifies that it brings no more real advantage.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Certainly, I am very interested on your approach on zone/object detection

The biggest problem by the development of DAC was the inquiry of the Trigger size.

Does somebody have an idea, how can one well solve this problem?

Here a small beginning:

After You have placed the Trigger in the editor, a Script puts a Logic on this position.

Now this Logic is shifted in 5 meters of steps over and over again to the north.

The zone will measure with an exactness of 5 meters.

After every step it is questioned where the Logic is ... within or outside.

If the Logic is outside, the Script is stopped and the distance to the Trigger is measured and is multiplied by 2.

OK, now the Y axis is measured.

The identical procedure must happen yet with the X axis.

If there are several zones, all that must be repeated several times.

Here a small time calculation...

the first example with only one zone:

The size of the zone = 1,000 x 1,000 meters

The size of the steps = 5 meters

It is measured from the center. This signifies that 100 steps are needed for every axis ... this is right?

All together 200 steps are required for this one zone.

Between every step lies a small break of 0.1 seconds.

Therefore, for this zone we need 20 seconds for the inquiry of the size.

If several zones must be measured, more time is required essentially.

Indeed the solution is quite good, but not in every position. An improvement would be,

to reduce the small break (from 0.1 to 0.01 seconds) ... or?

This is the next big problem. A Trigger has a sluggishness by chance 0.5 seconds.

Below this time a Trigger recognizes no changes.

If you know what signifies that ... for our zone we need instead of 20 seconds, now 100 seconds (with only one zone).

This is not everything ... we must still generate the way points and generate the Units.

OK, if You begin DAC, You can insert a break and get a coffee;-)

Here a real time measurement with DAC:

1 zone [1,000 x 1,000 meters]

80 generated ways points

90 generated Units in 20 groups

required time: 22 seconds

another constellation:

4 zones [1,000 x 1,000, 3,000 x 500, 1,000 x 2,000, 2,000 x 2,000 Metrer]

216 generated ways points

146 generated Units in 32 groups

required time: 43 seconds

I think this are useful values.

Please, excuses to this long Posting.

bye

silola

[Mr_Tea 0]

Great project.

The problems with the bridge are "normal". They are not caused by your work. I´m 99.9% sure on that.

The required time for the calculation depends on oure cpu power i think. What prozessor do you have?

[honchoblack 2]

thank you Shiola for the long reply, it gives a good insight on your work in porgress on the DAC engine

the bridges are a quite known problem, and I guess most of the mission designers stay far away from bridges with their missions

Concidering the long time to measure the spawn/waypoint zones, I would suggest using predefined zones, It should be sufficient if you use a couple of different zone sizes (e.g. 100x100, 300x300, 600x600, 1200x1200, 2400x2400, 4800x4800) and maybe some that arent square (e.g. 100x300, 300x100, 600x1200, 1200x600, 2400x4800, 4800x1200) and work with these predifined zone sizes, to safe the long zone calculation.

This would mean that you could still use the zone measurement, if a mission calls for many different sizes, or use a combination of these two (dynamic sizes and predifined sizes) to cut the calculation time down.

I think that even those predefined zones would be sufficient, but to have a way to detect dynamic zones would still be nice and usefull to have incoperated in the DAC engine

The next thing that would interest me, is how you detect objects (trees, houses .....) and the water, to place the waypoints avoiding these objects?

Keep up the good work, you got a very interesting project going on here

[silola 1086]

hi,

the required whole time is used up by 3 components:

Measuring the zones

Generating the way points

Generating the Units

Measuring the zones does not need so much time like it seems.

The example what I have called, should make clear with which problems I

had to fight;-)

However, I have found a way, that the required time for measuring the zones

essentially reduces.

In addition, the time need may not increase essentially, if several zones

are used.

Here again an example that only measuring the zones makes clear:

1 zone (1,000 x 1,000 m)-> required time = 5 seconds

3 zones (different dimensions)-> required time = 7 seconds

5 zones (different dimensions)-> required time = 8 seconds

How Do you see, is this absolutely justifiably, or You do not mean?

Apart from, I did not want that any values must be predefined.

It should function so simply as possible.

This was a quite important step by the development of DAC

The rest of the time is required for the way points and the Units.

How this functions, I explain later:-)

?(The required times for the calculation depends on oure cpu power i think. What prozessor do you have?):I have an AMD 3000+

Please, remembers that without DAC all Units must be placed in the editor and also a lot of way points.

If OFP must initialize such a mission, some time also passes.

This initialization is saved with DAC.

bye

silola

[Mr_Tea 0]

This tool save so much time, that I will have no problem to wait a little or a bit longer at mission start.

[deanosbeano 0]

ty for the reply shiola, i think i understand your answer. . i will test when released and maybe ask again. ty keep up the good work.

[silola 1086]

hi,

today I had been able to optimize the initialization something

with the old settings:

4 zones [1,000 x 1,000, 3,000 x 500, 1,000 x 2,000, 2,000 x 2,000 Metrer]

216 generated ways points

146 generated Units in 32 groups

required time: 43 seconds

with the new settings:

4 zones [1,000 x 1,000, 3,000 x 500, 1,000 x 2,000, 2,000 x 2,000 Metrer] = 6 seconds

226 generated ways points = 13 seconds

138 generated Units in 36 groups = 11 seconds

required time: 30 seconds

bye

silola

[honchoblack 2]

good job, 31% improvement on the time for the initilization is quite an accomplishment, if you keep up improving at this rate there wont be any time to wait left

[silola 1086]

hi,

here a small news...

I have decided to insert a small optical control,

so that everybody has at least some control about the independent life of DAC ;-)

What must you make for it?

You must copy an aggregation of markers in your mission...

You must adjust the variable "DAC_Marker" on "true". That's all ;-)

What exactly does it do?

After You have start the mission, goes on the map and observes like

The zones are measured

The way points in the zones are generated

and the different type of Units are placed

It also does fun to watch, besides.

In addition, you see in the later course of the mission which ways the Units go

and you get a feeling for what happens in a zone.

However, this control is also important if you want to observe the effects,

after you have changed one or other parameter for the waypoints generation.

Beyond it, DAC recognizes whether xcam was initialized and it stores

all generated waypoints in the respective lists.

Then still the possibility to recall all assigned way points of a group.

You can exactly examine which waypoints every single group owns.

These are only a few control instruments to keep the overview by the development

of a mission a little bit and to see whether DAC works properly.

bye

silola

[Baphomet 0]

I love technical improvements like these, nothing renews the game's appeal more than innovations like these.

[silola 1086]

hi,

here a few information like in DAC the way point generation can be influenced.

An adaptation must be carried out only, if, for example

the island this requires, or special conditions are.

The default settings of DAC is to be used for many islands.

For every way point type there are 6 parameters:

_checkRadius = 15

_checkMaxH = 1000

_checkMinH = 1

_checkObjH = 30

_checkAreaH = 25

_checkNear = 0

_checkCount = 200

On top the values are, for example, the defaults for infantry.

_checkRadius:

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

This value fixes the size of the area in which objects should be scanned.

However, this radius is also the inaccuracy with the way points

are done. However, a bigger radius also signifies more time with the generation.

_checkMaxH:

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

This value determines the maximum height value which a way point may have.

The picture below shows that way points were generated only by a height to 300 meters.

_checkMinH:

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

The identical, only in other direction.

The picture shows way points which were generated from a height of 300 meters.

It also functions of course that way points are between 2 values.

The next picture shows way points which were generated between 200 and 300 meters.

Therefore, waypoints on water are also possible...

....

[silola 1086]

...

_checkObjH:

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

This value determines the objects which may be in the Scan area.

Besides, the height of the object is measured. This method does not let itself with all objects

apply, in particular with buildings not.For building other criteria must be used.

Below the picture shows way points where no objects appear higher than 4 meters are.

_checkAreaH:

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

With this parameter the valid height relations are determined.

The next picture shows, that, for example, no way points in impassable ones

Areas are generated.

This value is used, for example, in addition to search suitable areas for helicopter landing fields.

In the picture below you see well, how perfectly DAC them 5 helicopters landing fields has determined.

There are no annoying objects and the land area has a level course.

_checkNear:

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

Herewith you can adjust the distance of the generated waypoints.

The picture shows several way points which have all one distance of 200 meters together.

_checkCount:

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

This setting determines how many attempts DAC undertakes a waypoint to find,

before DAC spends an error message that the zone is not to be used.

With the whole settings you must follow always, that DAC

all settings can also use.

bye

silola

[mcpxxl 2]

Hey Silola !

Is your email down ?

[silola 1086]

@MCPXXL: No, unless You want to send me a video