silola

Hi, if you get an error, first try this little change: Greeting Silola

Hi, You have to start the script like this (Init line): Greeting Silola *edit* I have missunderstand your script I think :-/ I had thought that you want to check a single vehicle and then send the results to all clients.

Hi :) please try the following script. It's not tested yet because I'm at work :( private ["_vlc","_startgl","_landlogic","_action"]; _vcl = _this select 0;_startgl = objNull;_landlogic = objNull;mDistance = -1;_action = true; if(isServer) then { _startgl = "logic" createvehiclelocal [0,0]; _landlogic = "logic" createvehiclelocal [0,0]; while{_action} do { sleep 0.01; if((position _vcl select 2) >= 1) then { mDistance = 0;publicvariable "mDistance"; if(local player) then {player sidechat "measuring jump distance"}; _startgl setpos position _vcl; waituntil{((position _vcl select 2) < 1)}; _landlogic setpos position _vcl; mDistance = round(_startgl distance _landlogic); publicvariable "mDistance"; if(local player) then {player sidechat format ["%2 jumped %1 meters!!!",mDistance, name driver _vcl]}; sleep 1; } else { if((getdammage _vcl) == 1) then { _action = false; if(local player) then {player sidechat "vehicle destroyed"}; exitwith {{deletevehicle _x}foreach [_startgl,_landlogic]}; }; }; }; } else { while{_action} do { waituntil{(mDistance > -1) || ((getdammage _vcl) == 1)}; if(mDistance > -1) then { player sidechat "measuring jump distance"; waituntil{(mDistance > 0)}; player sidechat format ["%2 jumped %1 meters!!!",mDistance, name driver _vcl]; mDistance = -1; sleep 1; } else { player sidechat "vehicle destroyed";_action = false; }; }; }; Greeting Silola

Hi, I've built a new init hint. Nothing special, but it looks a little bit better than the old one :) Greeting Silola

Hi :) Hey m8, the basic idea of DAC is to generate units, not to delete them :D Maybe I have to build a new script-pack called DAD (Dynamic-AI-Deleter)...haha. hint: If you deactivate a zone, this process has the same effect as deleting of a zone. Let's see, maybe I still have time left for this *MadRussian* function ;) Greeting Silola

Hi, please note that the new function requires a certain condition and has one limitation: 1. DAC must have been initialized with at least one zone. 2. New zones can only be inserted one by one. You must therefore wait until a zone is fully integrated, before you add another zone. Normally DAC can generate waypoints in up to 4 zones simultaneously. But I think that this limitation is acceptable. Greeting Silola

Hi :) i0n0s, you are crazy? I had always hoped that nobody has this idea because it involves a lot of effort. But hey, I'm crazy as u and so, yesterday I worked hard on such a function. And yes, now with version v2.1 it's possible to create a new DAC zone on-the-fly :D FIXED, now you can skiptime and and everything behaves as it should, for example respawn + deleting of units&vehicles FIXED, zones may now be placed in exactly the same position. DONE minor things: -------------- - reducing of mixed groups DONE - correct respwawn of mixed groups DONE - spawning vehicles with more than 1 gunner DONE - Define units types, which allows suppressedFire / DAC_SP_Soldiers = ["RU_Soldier_MG","USMC_Soldier_MG"....] - Define the timing for suppressedFire | (whole time, count interruptions, duration of interruptions) | _setSupTime = ["2 + ((skill _leader) * (3 * DAC_AI_Level))",2,5]; - Define the timing until the AI leaves its cover, for example, to retreat or advance (after a group has first enemy contact) | _setHidTime = ["(((10 * DAC_AI_Level) + ((_target distance _leader) / 5)) / ((count units _group) + 1))"]; Greeting Silola

Hi and sorry, but I have spent several days in my bed because I had contracted a severe respiratory infection. Therefore I could not respond the last days :( But now ... it's me little better every day, and I get back my concentration. Ok.. @MadRussian: --------------- After you've told me the whole "marker" story ... you've convinced me :-) My Suggestion: You make your marker functions ready for DAC V2.1 and describe the use of the functions, so that I can include that part in the readme. So...You and your functions will get a permanent place in the DAC and the DAC readme :D In addition, I will expand the existing method: DAC zones then can include custom waypoints, after they were moved. Condition is then that the waypoints are in the catchment area of the zone. Any number of custom waypoints can be predefined somewhere on the Map. Once they are detected by a zone, they are also involved. @Muahaha: ------------ yes, like MadRussian said, DAC can generate arbitrary units. You can even build your own combinations of units from different mods. And each zone can load their own combination. This is really very simple and very varied. However, DAC can not just spawn units, but also respawn units. This means that repeatedly new units penetrate into the mission area, and it leads to very long firefights ... if u want. @DMarkwick: ------------- You have really written a DAC tutorial? LOL ... this I have never seen m8, sorry. Okay, I'm waiting for your link ;-) @andersson: ------------- Do you mean "spawn" or "respawn" of units? I think you mean the respawn, since you can directly affect the time of "spawn" in the condition field of the trigger (zone). @becubed: ------------ Hey scott, your pictures tell me: "I must have this nice tool" ... hehe. I think something like this could be a big help for people who are as lazy as you or crazy as me :D Also interesting, because with the release of DAC V1.0 (OFP) an additional tool called "DAC zonewriter" was released. I think the basic idea was the same (idea from MCPXXL, because he is lazy as you *indietischkantebeiss*) Do you know this tool? Here are a few old pictures: http://img256.imageshack.us/img256/7678/zw2.jpg http://img525.imageshack.us/img525/3052/zw1.jpg http://img689.imageshack.us/img689/922/zw3.jpg And yes ... if u ask me ... I would like to have a similar thing done for V2.1 :bounce3: Greeting Silola

Hi :) @DMarkwick Yep, it's only important that you re-placing these logic(s) before the DAC is initialized. The same applies if you place a zone on a new position (and maybe all player units), first, place the logic(s) to the new position, then move the zone. @MadRussian I've test your demo-mission and it's all (functionality) clear so far (really good scripted functions) :) But there are 2 things that I must, for exactly, ask u again ... In your zone there are only 5 waypoints. If now 3 waypoints are replaced, it is highly likely that the 3 groups are affected by this change. That's okay and understandable. But what about a bigger zone, where u create 10 groups and 50 waypoints, so there are more random routes and the groups not get the same waypoints... How do know which waypoints are in use and which waypoints you need to replace, so it makes sense? If you do not want to selectively replace the waypoints, then it's okay. The waypoints were then randomly replaced. But then it can also happen that the user-defined waypoints will not be used. But anyway, your marker solution is really good and much usefull ;) The second thing ...the movable custom waypoints. It is true, DAC can not move these waypoints. Once a zone is moved, they are useless. But what role have these custom waypoints? In my opinion, to place waypoints at prominent locations within a zone. For example, in the vicinity of certain buildings, or on relevant positions for a mission, etc. Now, if u move a zone, and the positions of the custom waypoints would also (moving relative to the position of the zone), then these positions would be absolutely useless, because there are now new interesting positions within the zone, but on other positions. If you know exactly, on what position should be placed a zone, you could insert pre-defined custom waypoints, which then will make sense again. Ok, these are the points which seem not really clear to me. Maybe u can help me at this stage :) Greeting Silola

Hi, For this prob I've build a simple solution (simple because I want to release the DAC this year ... hehe ) You can place one or more logic units within a zone and define a distance, so no waypoints will be generated at this places. This means also that no units are generated in these areas (At the start of the mission). But please consider that these areas are crossed by units....after a while. About the mixed groups ... I've done some tests and I am initially pleased with the first result. The vehicle(s) within a group, adjust their speed to the speed of the soldiers and it's looks okay. Maybe this is evident from the following pictures ... I took the test with only one vehicle. How it behaves with multiple vehicles, I must study more. Next, I have to integrate the reduction of these units, so that only the vehicles are calculated on the distance. I must try this behavior first, but I think I can solve this problem (hope so). Instead of this entry for tanks: [5,1,30,6], you make the following entry: [5 [1,3,5],30,6] ... I hope this is easy enough. Ok Mad, I will test your work tomorrow :-) Bye Silola

Hi :) @MadMadRussian: 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

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:

Hi :) 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

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. 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... 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

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: Can you tell me one or two examples where your functions can be used wisely? and ... 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

Hi :) 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. :) 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 ;) ... 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

Hi, If you look at the last picture, you will find that a polygon requires a regular zone. This is necessary to start the (poly) zone. So, the correct position for the logic unit remains still the center of the regular zone ;) Greeting Silola

Hi, thanks for the comments and your interest :) This is really a very good idea, but I think the effort required for the implementation, is disproportionate to the benefits. Moreover, this would consume additional performace, which I would rather use elsewhere ;) In the new version this problem is already solved. You need only to place each logic unit in the center of the corresponding zone. A simple distance query then determines the membership of the logic units. I must say that I have not seen any restrictions so far regarding to the time limit. Ok, I've made some changes in the code, but I have not made any major improvements. I think that the DAC code has a solid structure. Therefore, the DAC has no problems with the script time limit. But wait, there is one place where I felt the limitation...the DAC_Marker. The more units are displayed with markers, the more it runs jerky :( But that's not really bad, because the markers should be used only during the development phase. Since DAC V1.0 I have still the idea in my mind that the DAC is able to process various AI-addons. But that would mean that it requires a small cooperation between the AI scripters, to create a common interface so that data can be exchanged. Greeting Silola

Signed.

Hello, at the beginning of Arma1 I had started the project "XCam2" for Arma (Some of you may know the Xcam for OFP), but a little bit later I have terminated this project, cause I did not had enough time left :( Now I'm working on DAC 2.1 and I need urgently such a tool. So I have re-activated this old project and I hope some day after the release of DAC 2.1, I can also release this little helper :) The picture below shows an early version: I hope u like it. Greeting Silola

Hi PataPalo, thx for your nice comment :) Did you read the readme? If yes, then you may have noticed that DAC is very complex and there are many features. It is very important to check all the possibilities for errors, so the whole package runs error-free. I think you understand the problems associated with it. So, please be patient. But stop ... this is the "DAC2.0 > Arma1" Thread :butbut: Greeting Silola

Hard to believe what you have done, Dslyecxi :eek: Really professionally implemented and very easy to read. But when comes the German version? :D Greeting Silola

Many thanks Maruk :)

Hello, I have the same probs here :-( After some minutes of playing (Whether in the campaign or do some attempts with the editor), ArmAII CTD without any message. (ArmAII German release version) I've noticed that shortly before my harddrive works very hard. I have try different settings in the graphics options, but without any success. My system: Win XP SP2 Intel E6600@2.4Ghz Asus P5N-E Asus ENGTX280 - 1GB VRAM - 185.81 SB Audigy2 ZS 2 GB RAM My Settings inGame at the moment: All settings on "HIGHT" (not very hight) VD = 1600 m (standard) Fillrate = 100% Until now I have started 5 times the first mission in the Campa and every time I had these crash - after 5-10 min. in game. Sorry, but I'm a little bit frustated :( Silola Hint: Still in Mission 1, when I open the map [M] I can't move and zoom the map, only on the edges. I think the prob is an invisible (big) dialog or control element.

Hi, it's not very hard to switch DAC to an different working directory ;-) Ok...for example u want use a folder named "AiMod". First rename your "DAC" folder into "AiMod" ;) The next step is to load all dac scripts with Notepad++ (Notepad can be open any number of files simultaneously) There u use the function "Search and replace in all open files" : search for: DAC\ replace with: AiMod\ After that action u must save all modified files. And the last action is to modify the DAC init line in your init.sqs (init.sqf): execVM "AiMod\DAC_Config_Creator.sqf"; That's all :) Greeting Silola