Jump to content

silola

Member
  • Content Count

    1041
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by silola


  1. hi smile_o.gif

    That should normally work without problems. You need always a master zone. That are the zone, where the heli is generated and is stationed.

    You can connect then as many as desired waypoint zones with the master zone. Here an example with 1MZ+3WZ zones:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    [hz1,[1,0,0],[],[],[],[1,2,4],[0,0,0]]exec "DAC\Scripts\DAC_Init_Zone.sqs"

    [hz2,[1,0,0],[],[],[],[4],[0,0,0]]exec "DAC\Scripts\DAC_Init_Zone.sqs"

    [hz3,[1,0,0],[],[],[],[3],[0,0,0]]exec "DAC\Scripts\DAC_Init_Zone.sqs"

    [hz4,[1,0,0],[],[],[],[4],[0,0,0]]exec "DAC\Scripts\DAC_Init_Zone.sqs"

    DAC sends the heli randomly into one of the four zones. If the heli flies e.g. to the zone “z3â€, then he will approach there 3 random waypoints.

    If the heli flies to the zone “hz2â€, then he has to settle 4 waypoints there smile_o.gif

    bye

    silola


  2. hi,

    my version I cannot give you unfortunately tounge2.gif

    The contained changes and innovations, you can not note without a reasonable Readme.

    It is by the way now also possible, while the mission runs, to reload at any time a new "Config_Unit" and a new "Config_Behaviour" for each zone smile_o.gif

    Camps can be assigned now completely simply to individual zones. Thus the Respawn can be divided and proportioned optimally.

    Camps have now their own “Conigâ€, whereby now substantially more possibilities are ordered....and so on.

    And… the moveable zones are also cool. Either the units move normally to their new zone, or alternatively, those units directly there are positioned, in order to take up their new waypoints then wink_o.gif

    bye

    silola


  3. hi matt,

    try this...

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">crwgrp = group this; "_x moveincargo M131" foreach units crwgrp

    and add this...

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">crwgrp = groupthis; "_x assignascargo M131; "_x moveincargo M131" foreach units crwgrp

    bye

    silola


  4. hi again smile_o.gif

    @mcbean:

    In principle at least one Camp is needed, in order to activate the Respawn.

    It is however possible to set all Camp objects on a not relevant position.

    It must stay only one object, so that at this position units can be generated.

    This object must be then only an invisible helipad.

    With this action you reach that the units are generated not in a Camp,

    but only at a position, which determined DAC randomly.

    And so you can make it:

    First you change the "DAC\DAC_Config_Units.sqs" :

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Unit_Pool_C = ["usa_vlajka.pac","HeliHempty","HeliHempty",[100,3]]

    Then still another small change in the Script “DAC \ KI_1 \ DAC_Move_Camps.sqs†:

    Below this line "@((getdir DAC_StartDummy) > 170)"

    you insert this new line:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@((getdir DAC_StartDummy) > 170)

    {if(!(_x == _buildingA)) then {_x setpos [0,0];if(format["%1",typeof _x] == "fire") then {_x inflame false}}}foreach _camparray

    Unfortunately the Respawn cannot be shortened, since OFP needs a certain time,

    until actually no more units are in the group present.

    DAC needs this waiting period, so that the new units in correct order are generated

    and also, so that enough place is present in the group.

    bye

    silola


  5. hi,

    @Combat-Agent

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Im making a MP compatiable mission that uses DAC. Its basically a CTI with DAC and CoC CE.

    My problem is on MP the large amount of troops generated lag the crap out of the server computer.

    The clients are just fine, and have all the fun.

    I was wondering is there some sort of way to reduce the lag but keep the density of enemy generated

    troops on the island. I have reduced the amount of groups, but the result lessened the intensity

    of the overall mission. Ill probably just have to use a smaller island. But i figured I asked.

    And oh by the way, I am using camps and respawn.

    That the server is overloaded, must not be an DAC problem. It can have many reasons.

    DAC is besides not able to make from a not playable mission suddenly a playable mission.

    DAC has to fight with the same problems, like other mission.

    For example on a very extensive island, if many groups are generated,

    which besides of hight Polycount units consist, also DAC thereby will have problems.

    Here a few tips, which you should consider:

    - Does the mission run on a “dedicated server�

    - Deactivate the DAC_Markers. These are not supported in MP games.

    The marker scripts do not have to be unnecessarily activated.

    - Examine whether the logic “server†is present.

    - Is the group reduction activated ? And are the attitudes optimally selected ?

    - Is the deletion of units activated? Is the attitude optimal?

    - If you deactivate the group reduction, do you notice then that it runs still more badly?

    - Examine the number of groups, which are generated on each sides. How many is there?

    - Reduce something the number of groups, which are generated.

    - Reduce the number of units, which are generated for each group.

    - Generate rather somewhat more infantry than vehicles. Then can be reduced also more groups.

    - Test the mission on an standard island, with standard units. How does the mission behave then?

    - Are further scripts on group level active, or even on unit level, which runs on the server?

    If possible, deactivate these scripts for one test, to examine whether the performance is affected by it.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">And one more question. Sometimes ill get a DAC error saying that process interupted because a camp is not suitable. Why is this?

    This error meant that in a zone, in which one or more Camps are to be generated,

    it gives no suitable positions there.

    There are several possibilities of minimizing an arising of the error:

    - Increase the size of the zone, so that there are more possibilities for the placement of Camps .

    - Tries to find a better position for the zone.

    - Change the values for Camps in the DAC_Config_Waipoints.sqs

    ;\\\\\\\\\\\\\\\\\\\\\\\\\\\

    #WP_Typ_5

    ;-----------> | Camp |

    ;///////////////////////////

    _CheckRadius = 40

    _checkAreaH = 20

    _checkMaxH = 1000

    _checkMinH = 5

    _checkNear = 100

    _checkObjH = 4

    _checkCount = 500

    _TempWPArray = DAC_WP_Pool_C

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Another question, I want to make more buildings appear with the camps just for eye candy.

    I tried editing the Dac_group_camp or whatever the script was called, but never got it to pump

    out the extra building.

    Wait for DAC version V1.2 wink_o.gif

    I answer the other questions later...

    bye

    silola


  6. hi,

    @Zendjir

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">-But then, when some groups are killed, they respawn, and that's when the sh** hits the fan. When monitoring the behaviour of the groups on the map it seems they don't really know what they are supposed to do. Sometimes they move in directions where no waypoint is present. Sometimes they pause for no apparent reason. Sometimes they just move around aimlessly in the zone where they have been created. And occasionaly they do seem to care about their objectives and move towards a waypoint.

    Unfortunately I cannot reconstruct this failure correctly yet confused_o.gif

    I can only say that there are no problems with the following attitudes with me (and your mission).

    Everything functions in such a way, as it should function. Also after several Respawns...

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

    DAC_KI_Level = 4

    DAC_KI_AddOn = 1

    In addition I deactivated your Scripts first times.

    I have however still a few important notes for you, which you should consider:

    # Avoid the game acceleration. It is not completely safe whether that causes errors.

    # Generate always somewhat more waypoints like being needed. If a group is to get for example 10 waypoints, then should be available 12 to 15 waypoints for the selection.

    In the following a picture, which explains still further characteristics....

    dacxcam4cj9.jpg

    1) Fights will not always take place at the desired positions.

    They can shift outside of the zones. That comes by the dynamics of DAC (and by the existing dynamics of OFP) smile_o.gif

    2) You should make certain that zones of east and west are not to close together.

    It can happen otherwise that the Camps is generated nearly next to each other.

    That would contribute then also again to inadvertent fights.

    3) In each master zone at least one waypoint is generated, so that the units can be produced at the beginning there.

    By the fact it can happen that a group moves again back, in order to reach the waypoint in the master zone.

    4 + 5) Units move not in principle on the shortest way to their waypoint.

    Often they use a small detour and move thereby in an elbow towards their waypoint.

    That comes not from DAC, but is a normal behavior of the OFP AI.

    6) Because the zones in the north and in the west are linked can it pass that the units move from the one to the other master zone. And again not on the direct way.

    Here still another picture of another zone placement,

    like it functions also perfectly and also without any Failure.

    In this example can be generated some more units, since the distances are somewhat larger.

    dacxcam5ye3.jpg

    But I will accomplish still another further test. smile_o.gif

    bye

    silola


  7. hi,

    It can also be that you do not link the zones correctly.

    In your case it would have to actually be 4 zones.

    Here a picture, how it looks supposed with you...

    zone1rg9.jpg

    And here a picture, how it must look...

    zone2ts4.jpg

    Each masterzone has its own waypoint zone, with which it is linked. Perhaps that helps you icon_rolleyes.gif

    EDIT: Importantly... The Logics for the individual waypoints, may be not in the same zone !

    bye

    silola


  8. hi,

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">- How can I remove or circumvent the 'take cover' behaviour of DAC groups? Or, framed in another way; how can I ensure that DAC groups take only little pauses in their movement routines and are nearly always on the move to their assigned waypoint?

    - How can I prevent groups from leaving their patrolzones. In a mission I'm currently working on I got the troops from 2 zones that are supposed to defend 2 town joining the troops that are supposed to attack an enemy town. Thus leaving their assigned towns defenceless.

    You can make the attitudes in the script “DAC_Config_Behaviour.sqsâ€.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_setPause = [5,5,10,25,5]

    Here you can set the break times for each units category, which is inserted by the groups between the way points.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_setSupport = 0

    This attitude ensures for the fact that the groups from the appropriate zone can not be requested for support.

    The groups therefore remain in their zones.

    bye

    silola

    Further information > see Readme page 23 smile_o.gif


  9. hi,

    Quote[/b] ]It would be nice that mission makers are able to edit the options within the editor, by usage of a gamelogic or whatsoever.

    as I shown earlier, by simple if paramater=scalar then define the parameter, otherwise take the parameter that was set before, like the setting in the gamelogic.

    This way Editors can do it both ways.. editing the config or changing it while mission debugging etc

    I thought over it. A conceivable solution would be the following (that is only one example):

    For example for DAC_Marker and DAC_Com_Values.

    For these two adjustment possibilities 2 Logics are needed.

    Each Logic gets as much way points, as parameters are needed.

    The first waypoint corresponds to the first parameter, the second waypoint the second parameter etc.

    This waypoints must be moved now simply into the respective range of the markers,

    in order to set the appropriate value. Thats all smile_o.gif

    The first parameter (true/false) is reached by the value “azimuthâ€:

    0 = false

    1 = true

    2 = disabled (values by script)

    Here a small illustration, which makes the principle clear.

    dacsettingsrz5.jpg

    Is this solution interesting?

    bye

    silola


  10. hi smile_o.gif

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Hey Silola, sorry for the delay but I've sent you an PM with a link to the formation script(s), keep up the great work, can't wait for the new version!.

    I noticed your PM. Thanks for the link. Unfortunately I had still no time to test it confused_o.gif

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">I'm having an idea that is building upon TacRod's with the hint disabling. I thought about a "release version master switch". Didn't found a better name for it. It would be a boolean among those in DAC_Config. It's purpose would be that if you set it to true, it would override some setings in DAC_config: markers to false, hints to false, comunications off and maybe a dark screen and disableuseriput while DAC initialises. This way the guy using DAC wouldn't have to tweak 5-6 variables when making a release version. In short, it's like in programming, when you turn debug options on/off. I think this isn't hard to implement, but also it isn't so important also. Just an idea.

    I split the attitudes for DAC_Marker and DAC_Com_Values now.

    DAC_Marker = [false,0,0,0.3]

    DAC_Com_Values = [false,0,0,0,0]

    In each case if the first value is set on false, all other parameters are ignored.

    If they are set on true, the parameters have the following meaning:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">==================================

    A B C

    | | |

    DAC_Marker = [true,1,1,0.3]

    ==================================

    A = Unit Marker

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

    0 = No markers for units are indicated

    1 = Only markers for enemy units are indicated

    2 = Only markers for friendly units are indicated

    3 = markers of enemy and friendly units are indicated

    B = Zone&WP Marker

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

    0 = No markers for Zones&WPs are indicated

    1 = The markers for Zones&WPs are indicated only during the initialization

    2 = The markers for Zones&WPs are permanently indicated

    C = Marker Refresh Value

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

    Value = The actualization rate for the markers

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">==================================

    A B C D

    | | | |

    DAC_Com_Values = [true,1,0,1,3]

    ==================================

    A = Hint(Initstatus)

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

    0 = None Hint is shown during the initialization

    1 = Hints are shown during the initialization

    B = Cuttext(Processbar)

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

    0 = None Cuttext is shown during the initialization

    1 = Cuttext are shown during the initialization

    C = DAC system messages

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

    0 = DAC system messages are not active

    1 = DAC system messages are active

    D = DAC radio message

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

    0 = DAC radio message are not active

    1 = DAC radio message only on enemy side active

    2 = DAC radio message only on friendly side active

    3 = DAC radio message on both sides active

    Therefore there are two values must set on false, in order to deactivate everything.

    The attitudes of the parameters remain thereby.

    I hope that you agree with it icon_rolleyes.gif

    bye

    silola


  11. hi,

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">The next is my experience, not facts: (actually this is a fact) respawn is done with a counter end, not a time end

    That is absolutely correct !

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Is there any possible way for the tanks to keep respawning for a certain time? or do i have to make a camp which keep spawning tanks? dunno hows thats done?

    In order to be able to respawn new groups, you need at least one Camp.

    I recommend to you to generate first only one zone with one camp.

    In addition you should activate the DAC marker for a first test.

    So you can determine whether there are problems in the zone to find a suitable place for the camp.

    The zone with the camp can be placed somewhat outside. Make the zone largely enough,

    thus for DAC sufficient area has for the search.

    Here an example of an script call, which produces a camp:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[z2,[1,0,0],[],[],[],[1,1,50,0,100,5],[0,0,1]]exec "DAC\Scripts\DAC_Init_Zone.sqs"

    The Respawn is automatically activated thereby :-)

    You find more details still in the Readme. There also all parameters are described exactly tounge2.gif

    bye

    silola


  12. hi smile_o.gif

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">It would be nice to have an option to turn off the Hints that appear when DAC is successfully started (eg. "DAC is initialising", "You may start your mission", etc). Perhaps something like "DAC_Hints = false" set in DAC_Config_Creator.sqs,

    Such messages are very useful during the mission making process, but players don't really need to see such information

    That is a little thing. I will insert it...this evening tounge2.gif

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Does someone have good ideas, about implementing DAC on islands with many rivers? The only I'm having is making a small zone for every smaller island, but I don't have a good solution for respawn.

    Those are difficult conditions for DAC. But not impossible. For the moment I do not have the time to care me for this topic...sorry m8 confused_o.gif

    bye

    silola


  13. hi,

    @Extremeus Decimus:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Hey great work, Silola :tup: but i was just wondering is it possible to get general barrons custom formation script to work with DAC?,the script is started like so

    thx Extremeus Decimus smile_o.gif

    You can give me please a link, where I can download the "general barrons custom formation script" ?

    I could try then something out. Perhaps find I a solution for you smile_o.gif

    bye

    silola


  14. hi,

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">I'm a little confused.

    I'm res, and I want my enemy to be east, so should the last parameter of the script look like this:

    Normally this constellation does not function: DAC_Players on side res. I wrote that also in the Readme.

    But there is a solution, which will then be contained also in the patch.

    There is however still a delimitation: Resistance must belong to the side west or east !

    unbenanntbo6.jpg

    Adjust the following in your case please:

    In the script “DAC_Config_Creator.sqsâ€: DAC_Res_Side = 1

    In the editor: Resistance on side “westâ€

    Then you must modify still two scripts. In the script “DAC\KI_1\DAC_Select_E_Target.sqs†must look the code block “#readplayers†as follows:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#readplayers

    {if((format["%1",side _x] == "East") && (!(_x in DAC_East_Units)) && (alive _x)) then {DAC_East_Units = DAC_East_Units + [_x]}} foreach DAC_Players

    ?(DAC_Res_Side == 0):{if((format["%1",side _x] == "Guer") && (!(_x in DAC_East_Units)) && (alive _x)) then {DAC_East_Units = DAC_East_Units + [_x]}} foreach DAC_Players

    ~0.1

    and in the script “DAC\KI_1\DAC_Select_W_Target.sqs†must look it in such a way:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#readplayers

    {if((format["%1",side _x] == "West") && (!(_x in DAC_West_Units)) && (alive _x)) then {DAC_West_Units = DAC_West_Units + [_x]}} foreach DAC_Players

    ?(DAC_Res_Side == 1):{if((format["%1",side _x] == "Guer") && (!(_x in DAC_West_Units)) && (alive _x)) then {DAC_West_Units = DAC_West_Units + [_x]}} foreach DAC_Players

    ~0.1

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">And, I wan't the russians in the zone be at safe, patroling their zone, where all units should have their weapons on their back, but when I attack, will they go into their fighting position until the area is secured. Or if the player-side has killed them :p

    Wich behaviour should I choose in that case?

    okay, you must modify a code block into the “DAC_Config_Behaviour.sqsâ€

    For example these:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">;\\\\\\\\\\\\\\\\\\\\\\\\\\\

    #Behaviour_Typ_4

    ;///////////////////////////

    _setSkill = [0.8,1]

    _setCombat = ["white"]

    _setBehav = ["aware"]

    _setSpeed = ["normal","full"]

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

    _setFleeing = [0]

    _setFlighth = [50,60]

    _setPause = [1,5,5,5,5]

    _setSay = [["rus3","rus4","rus7","rus8","rus9","rus16","rus20"],["rus6","rus10","rus18"],["rus2","rus15"],["13"],["rus11","rus14","rus19"]]

    _setSupport = 0

    modify as follows :

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">;\\\\\\\\\\\\\\\\\\\\\\\\\\\

    #Behaviour_Typ_4

    ;///////////////////////////

    _setSkill = [0.6,1]

    _setCombat = ["white"]

    _setBehav = ["careless"]

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

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

    _setFleeing = [0]

    _setFlighth = [50,60]

    _setPause = [1,5,5,5,5]

    _setSay = [["rus3","rus4","rus7","rus8","rus9","rus16","rus20"],["rus6","rus10","rus18"],["rus2","rus15"],["13"],["rus11","rus14","rus19"]]

    _setSupport = 0

    “#Behaviour_Typ_4†meant, you must use the number 4 in the Script call -> [0,0,4]

    I hope that I could help you thereby icon_rolleyes.gif

    bye

    silola


  15. hi,

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">cba to read trough 28 pages, so a quickie.

    Is DAC supported by VBS?

    (I know this is not the place to talk about it, but a quick answer, and I shall leave it)

    np J W, as far as I know, it functions with VBS. SniperAndy from http://www.virtualbattlespace.info/ modified it easily. He had to adapt only the “DAC_Config_Units.sqsâ€. In this script the units types are put down, which DAC needs for generating.

    And those do not correspond as well known to those from OFP.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">I was just brainstorming...and thinking about the following:

    Is it possible to make a trigger that is let's say 1400, in the zone init I use the 2extra parameters... but state that the zone is 1000x1000... will DAC just only use 1000 of the zone or will it still use 1400? I ask this, because if I can make it like this, I can save another 4 triggers in my missions/templates and save even more..

    Cause I would then use the list of that trigger, to see if there are player troops marching in and activate the zone, or in case of objective destroy all enemies.. I can check if there is enemies alive and if not... deactivate the zone and tick off the objective...

    The trigger, remains always on the size which in the editor was specified. There is unfortunately no possibility of changing the size of a trigger by a script.

    That means thus that the triggers query always exactly the range, which was given to them in the editor.

    DAC uses the optional parameters exclusively, in order to ignore a measuring of the zones.

    bye

    silola


  16. hi,

    @kutya:

    ============================

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">This is probably basic scripting, but how do I add a DAC_Player through a script?

    DAC_Players = DAC_Players + [NameOfTheUnit] wink_o.gif

    After you produced a new group, you can add this group as follows to the array:

    {DAC_Players = DAC_Players + [_x]} foreach units NameOfTheGroup

    @sickboy:

    ============================

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">I was wondering... if it's possible to use 1 trigger for multiple zones.. I am unsure, but I think the more triggers there are on the battlefield... the more performance loss. So if I would like a stationary zone and a normal zone to be created, can I use the same trigger... I think I tried it but gave me errors, I'm wondering if it should work and if it doesn't .. if there would be a workaround

    Sorry sickboy, zones cannot be used unfortunately several times. But thanks for this tip. Perhaps I find a solution.

    bye

    silola


  17. hi,

    @sickboy:

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

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">I built a complete template system (not OFP's built-in template system, but my own), around DAC and many many features.

    These templates are also available to my community, for ppl that want to build missions for our servers... I mainly make basic, but great to play missions, as many of them as possible, while others invest more time in creating more detailed missions, but a lot less amount..

    Great thing Sickboy. This concept sounds very interesting thumbs-up.gif

    @Zendjir:

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

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">You are right that the way the script is set up it will make units behave more the same. Why I have done this is because of the fact that it makes AI behave more cautiously under fire. I was fed up with AI soldiers charging happily straight into enemy fire, so I created the script :). You are also correct in stating that it is a matter of opinion, you like it or you don't. However the script does save the original behaviour of the group and the group will adopt that behaviour when the area appears to be clear of enemies. Also, the skill of the units determines how fast they will see the enemy and so how fast the group will adopt 'stealth' behaviour. So a low skilled group will still get owned by a high skilled group, just not in under 5 seconds

    This sounds already better smile_o.gif Sorry, I had not look at your Scripts well enough.

    @Mr.Peanut:

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

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Do DAC groups follow the WP in the same order each time? Or is the route randomised for each circuit? I was just suggesting that the route WP be sorted in a way that minimises it net length. No matter to me. Easier not to bother with it!

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If I understand correctly DAC (on initialisation) sets a waypoint pool for each group. The group randomly selects one from that pool and goes there. Once the group arrives, it chooses another random waypoint from the same pool.

    What Kutya said, is absolutely correct. Even though many thanks for your suggestion smile_o.gif

    @Kutya:

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

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">1. Assume that I put all the group leaders of the mission in DAC_Players. If the group leader dies, will DAC generated units react to the rest of the group?

    Yes. Even if you put down only the leader of a group in the Array, DAC provides for the fact that the remaining units of the group are also put down there.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">2. In my mission I spawn and delete some groups many times. Will DAC units react to them after a couple of spawns? For example some Special Forces called for support.

    Are the editor placed units from what you talk?

    Why you spawn and delete these groups many times?

    I cannot confirm whether DAC reacts still correctly after such actions.

    I know however that DAC deletes the dead units from the DAC_Players array. To that extent it is better to register the new units again into this array.

    bye

    silola


  18. hi,

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">my +- 60 DAC Coop missions

    wow_o.gif

    @Zendjir:

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

    I am not sure yet whether your scripts do not influence too much the DAC AI negatively.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"it disables the 'target' AI for each soldier in the group"

    "it sets the behaviour of a group to 'stealth' and speed to 'limited' when an

    enemy is detected within 275 meters."

    In DAC the behavior of the units is dependent on the Skill of the leader,

    or on the average Skill of the whole group.

    The groups thereby not always behave immediately.

    This provides for change and dynamism.

    With Your variation the unities behave always after the same pattern.

    Now this is no criticism, only another point of view wink_o.gif

    In the next version DAC 1.1, the AI will also use buildings, if there is the possibility.

    The DAC will use his own building scanner. This can be activated optional in every zone.

    The scanner works, while the waypoints are generated.

    Then the grasped buildings are made available the for the AI. smile_o.gif

    bye

    silola

×