Rydygier

Hmm. We, I and Squint, do not see problem in 738. This RPT report is somehow familiar to me. Something like that I see not first time, but can't remember, where this error occured earlier. I remember, that last time cause was very strange - was needed objective triggers deleting and placing again. Did that now, but not hepled. Tommorow will try check this more deeply.

I haven't now time for test this myself, but in init.sqf you have syntax error in line 540 (RHQ_MArmor), where is comma, that shouldn't be here, after last element of an array: "T34_TK_GUE_EP1". Delete this comma and try, if this helped.

if you refer to that groups by using this: (for first patrol)and perhaps following in other triggers: (for second patrol) (for third patrol)etc. then this: Is no longer needed, as this is just another form of reference to the group, given only as example, and good only for sqf file. This: adds new entry to the initially empty MyPatrolGroups. (count MyPatrolGroups) will return number of currently present in the array elements, so, as index number of first element is 0, second is 1 and so on, this will give always first not used yet "slot" index in the array. This way, by set command, new spawned group name (_grp) will be added as new, next element in MyPatrolGroups array. For example, if array contains one element, eg: [group1] then count MyPatrolGroups is equal to 1. So on position of index "1" (second position) will be placed newly spawned group, so after that this array will look: [group1,group2]. Repeating procedure will give next element added on third "slot" and so on, and so on. Another, slower (but difference is meaningless here) way to do same is: MyPatrolGroups = MyPatrolGroups + [_grp];

So this act field will look like here with "my" method: ({alive _x} count units (MyPatrolGroups select 0)) < 1

No. This is wrong, and - why? Both, _firstpatrol and _secondpatrol (or whatever name) variable you define (=) when you need to use somewhere name of a spawned group (you said, that you will refer to that groups, i do not know, where and for what purpose you will do that...). MyPatrolGroups is filled automatically after each spawn, you define it only once, as empty ([]) in init sqf.

(as drop interval is very low already, but remember about particles limit, do not know exact number)

In the place, where you need to refer to these groups. After that code first patrol you will have under _firstpatrol variable (so for example code hint (str (count (units _firstpatrol))); in the same place (same file) will display on screen actual number of units in first patrol group), and second... well. Do I need to finish? :) Remove "_" from variables if this place is located inside trigger or another file, not inside same sqf file as "_firstpatrol = MyPatrolGroups select 0;" and " _secondpatrol = MyPatrolGroups select 1;". (there is more issues with so called scopes and local (_) variables, but nevermind for now).

Or, quick idea, try with: _snow setParticleRandom [0,[30,30,20],[0,0,0],0,0.01,[0,0,0,0.1],0,0]; change red array (range in meters for randomization of position of each flake [x,y,z] around source position (player)). If density become to low, add second source with same or other parameters. As there is limit of maximal number simultanously shown particles, the bigger area, the lower max density.

If you want, you can use two. But "my" way is really simple. You run spawn code as many times, as you want, each spawn the name of spawned group will be added to the array named MyPatrolGroups. Each of them may be obtained with this "select (number)". So in this method MyPatrolGroups select 0 is exactly same, as tankgroup1 and MyPatrolGroups select 1 same as tankgroup2 in "two files" method. Do, as you wish, but if you want to do some more scripting in the future, you will need to familiarize with such "tricks" (and more...), as these are more elegant, but, what more important, makes many things far easier and more effective.

Yes, but this time you will execute same code for both patrols, so tankgroup1 will be defined twice, and second patrol will overwrite first. In presented by me way, you can keep any number of groups in one variable.

Yes. Or better, do same way, as is done with position. nul = [getmarkerpos "vehpatrol1",[[i]classes here[/i]]] execVM "patrol.sqf"; and nul = [getmarkerpos "vehpatrol2",[[i]classes2 here[/i]]] execVM "patrol.sqf"; where patrol.sqf looks like: _spawnPos = _this select 0; _classArr = _this select 1; _config = [ classArr, //array of vehicle classes to random choose from east, //side of patrol _spawnPos, //point of spawn 5, //vehicles amount "FORM", //"CAN_COLLIDE","FORM","NONE" or "FLY" false, //if is locked "TANK", //"LIGHT","TANK" or "AIR". Matters, when crew class is not defined. Determines kind of crew units "RU_Soldier_Crew", //optional - class of crew members, set as empty string if not used "MOVE", //optional. Type of waypoints. Default: "MOVE" "SAFE", //optional. Behavior of waypoints. Default: "SAFE" (recommended for "onRoads" mode) "YELLOW", //optional.Combat mode of waypoints. Default: "YELLOW" "NORMAL", //optional. Speed of waypoints. Default: "NORMAL" "COLUMN", //optional. Type of waypoints. Default: "COLUMN" ["true","(units (group this)) orderGetIn true;if not (isPlayer this) then {(assignedVehicle this) setFuel 1}"], //optional. Type of waypoints. Default: ["true",""]; true, //optional. If patrol should be looped. Default: true true, //optional. If should be deleted initially added to that group waypoint(s). Default: true true, //optional. If patrol should move from nearby town to town using roads. Default: false 250, //optional. Matters only, when patrol is not in "onRoads" mode. Minimum distance of each waypoint from starting point. Default: 100 1000, //optional. Matters only, when patrol is not in "onRoads" mode. Maximum distance of each waypoint from starting point. Default: 2000 100, //optional. Matters only, when patrol is not in "onRoads" mode. Random placement radius for each waypoint. Default: 0 3, //optional. Matters only, when patrol is not in "onRoads" mode. Minimum number of waypoints (excluding start and cycle at end if looped). Default: 3 5, //optional. Matters only, when patrol is not in "onRoads" mode. From this value is randomized number of additional (above minimum) number of waypoints. Set to 0 to achieve exact, minimal number of waypoints each time. Default: 10 2000, //optional. Matters only, when patrol is in "onRoads" mode. Radius for towns search (maximum patrol checkpoints radius). Default: 5000 0, //optional. Matters only, when patrol is in "onRoads" mode. Minimum pause time in seconds at each waypoint. Default: 0 0 //optional. Matters only, when patrol is in "onRoads" mode. Maximum pause time in seconds at each waypoint (in each town). Default: 0 ]; _patrol = _config call RYD_Patrol; _patrol is the local variable that is an array contains both, group and its waypoints [group,waypoints]. To obtain group name use in the same file, after _patrol = _config call RYD_Patrol; such line: _grp = _patrol select 0; Things are more complicated, if you need to refer to the group name outside this file (do you? If not, this is not important). Global variable (without _) is sufficient, but, as same code is executed for both patrols, second patrol will ovwerwrite value of this global variable, so you must store first patrol group name in other variable before second patrol will be spawned, or use some setVariable technique, perhaps with array inside, that will contain each spawned group. EDIT: you can then add such line in init.sqf: MyPatrolGroups = []; and use such code in last part of patrol.sqf: _patrol = _config call RYD_Patrol; _grp = _patrol select 0; MyPatrolGroups set [(count MyPatrolGroups),_grp]; MyPatrolGroups will contain as array all group names of spawned patrols, where first may be obtained as eg: _firstpatrol = MyPatrolGroups select 0; second as: _secondpatrol = MyPatrolGroups select 1; and so on...

I don't know much about servers and such, but both cited code has syntax error, at the end should be closing bracket - } Anyway instead of using whole code from first demo's init.sqf better would be for example (not simpliest, but with minimal amount of changes): init.sqf same, as in my last demo - only call compile etc. line. patrol.sqf: _spawnPos = _this select 0; _config = [ ["GAZ_Vodnik_HMG","RW_T90","KamazRefuel","ACE_UAZ_MG_RU"], //array of vehicle classes to random choose from east, //side of patrol _spawnPos, //point of spawn 5, //vehicles amount "FORM", //"CAN_COLLIDE","FORM","NONE" or "FLY" false, //if is locked "TANK", //"LIGHT","TANK" or "AIR". Matters, when crew class is not defined. Determines kind of crew units "RU_Soldier_Crew", //optional - class of crew members, set as empty string if not used "MOVE", //optional. Type of waypoints. Default: "MOVE" "SAFE", //optional. Behavior of waypoints. Default: "SAFE" (recommended for "onRoads" mode) "YELLOW", //optional.Combat mode of waypoints. Default: "YELLOW" "NORMAL", //optional. Speed of waypoints. Default: "NORMAL" "COLUMN", //optional. Type of waypoints. Default: "COLUMN" ["true","(units (group this)) orderGetIn true;if not (isPlayer this) then {(assignedVehicle this) setFuel 1}"], //optional. Type of waypoints. Default: ["true",""]; true, //optional. If patrol should be looped. Default: true true, //optional. If should be deleted initially added to that group waypoint(s). Default: true true, //optional. If patrol should move from nearby town to town using roads. Default: false 250, //optional. Matters only, when patrol is not in "onRoads" mode. Minimum distance of each waypoint from starting point. Default: 100 1000, //optional. Matters only, when patrol is not in "onRoads" mode. Maximum distance of each waypoint from starting point. Default: 2000 100, //optional. Matters only, when patrol is not in "onRoads" mode. Random placement radius for each waypoint. Default: 0 3, //optional. Matters only, when patrol is not in "onRoads" mode. Minimum number of waypoints (excluding start and cycle at end if looped). Default: 3 5, //optional. Matters only, when patrol is not in "onRoads" mode. From this value is randomized number of additional (above minimum) number of waypoints. Set to 0 to achieve exact, minimal number of waypoints each time. Default: 10 2000, //optional. Matters only, when patrol is in "onRoads" mode. Radius for towns search (maximum patrol checkpoints radius). Default: 5000 0, //optional. Matters only, when patrol is in "onRoads" mode. Minimum pause time in seconds at each waypoint. Default: 0 0 //optional. Matters only, when patrol is in "onRoads" mode. Maximum pause time in seconds at each waypoint (in each town). Default: 0 ]; _patrol = _config call RYD_Patrol; then in triggers for both ammo boxes act field: First trigger: nul = [getmarkerpos "vehpatrol1"] execVM "patrol.sqf"; Second trigger: nul = [getmarkerpos "vehpatrol2"] execVM "patrol.sqf"; That's it. No additional triggers needed. Still can't tell, how it will behave in MP.

Some good news for air cargo fans. It seems, that after many houres of tests and bug hunitng I'm on good way to improve reliability of air cargo significantly. BTW already corrected some rare problems with arty fire and with idle orders. Still awaits boring impementation of air cargo fixes and some correction of morale calculations, when new groups are added under Leaders control during the game (to avoid morale drops because of that, and negative losses value for debug), but not sure, if will be possible anything here. This depends on free time, but next HAC version should be released soon.

There is many possible ways. Here is one of them, where spawned are three patrols, one UAZ each and each for one position marked by trigger. Function is called (in foreach loop) from separate sqf by Juliet radio channel (0-0-0) (repeatable). http://www66.zippyshare.com/v/36264493/file.html Like I said, there is many ways. Eg you may use random spawn position each time instead of "hardcoded".

Open VehPatrol_fnc.sqf, find function RYD_SummonV, go to the lines 150 (matters for air vehicles only): _plZ = (_place select 2) + 25 * _mpl; and 152: _place = [(_place select 0) + 25 * _mpl,(_place select 1) + 25 * _mpl,_plZ]; "25" number is a value, that you may change for yours purpose (set smaller, suitable value instead of each three 25's). It is position difference in meters for each axis separatelly. BTW you may also want to fix small issue in line 134, where is: _crew1 setSkill (0.1 + (random 0.25) + (random 0.25)) and should be: _crew2 setSkill (0.1 + (random 0.25) + (random 0.25)) (affects only one of the crew memeber skill).

During recent practice coding created some interesting in my opinion function, that allows to split a given square area (with any angle) to the selected number of square sub-sectors. Returned is nested array of locations, each for one sub-square and one separate for main location, that covers whole area. So, I'm thinking now, for what purpose this may prove useful? Any ideas? For now I had two/three: 1. In fact not my idea - heard about something like that somewhere. This may be very handy for some AI scripting (eg for my Hetman, but also on lower level) - if to cover whole map with such created square locations, there will be possible to bound by setVariable many data with each sector - topographical, tactical, other... By using this sectors AI can now to decide, which path will be optimal for movement, what send where, where to go, and which areas should be avoided, to analyze enemy presence per sector, can recognize and refer to certain areas... In one word to process bounded with sectors data in many ways, in many situations; 2. To make Arma (quasi)turn-based board game using map only, where real groups will become pieces, or only with markers - and here we have an practical example: crude, but playable chess on Utes map. You can choose piece by single click on it, next click will make this piece to move at closest square. For remove piece from chessboard - move it same way at one of circle markers. Script will not check correctness of the moves - any movement possible, all in the players' hands. Only HotSeat mode available, I'm afraid :). Chess AI is somewhere far beyond my skills. As pieces are used tactical markers... This of course can be applied to any map, also as hidden in action menu option, and used when there is nothing better to do, only boring & waiting, for example during the night watch... 3. Can be maded some kind of cellular automaton, as "Langton's Ant" from my avatar, but - what for?

Oh, no. Action cam was written for some earlier project, Eight Notches mission outro, to be exact. Some used here functions also was ready, taken from my private "library". Still, several days was enough for first version of cam script, this one is slightly changed. I have also other, third version, with UAV/satellite-like view for some weird micro-mission on Lingor, that wasn't released (rather excersise with dispays and controls basics than a mission). It is not as much work. Some eventhandlers, some loops and checks, several functions, waitUntils, set of relative coordinates for randomized view angle, dir and distance and voila. Action cam.

ArmaChess 0.1 - fixes, fixes, fixes... - AI improvements. I'm quite pleased with progress in both fields. Not seen a single stuck in this version (only un-removeable possibility will be stuck on terrain, but never saw this on Desert map). AI now is probably almost as complex, as may be with reasonable amount of coding. I'll not say, that now is smarter, than was, this is wrong word. Rather is less dumb. AI "thinking" may last now even 20-25 seconds, nothing wrong with this, even like it, these are more human-like delays now. And quite often effects seems to be like real chess player may choose. Only seems of course. AI will often push towards center or enemy king's position, will protect own king, and attack enemy, when possible, will avoid leaving own king under a risk, if possible, will sometimes choose position suitable for capturing some enemy piece... Such kind of things. Does not foresee the effects of moves ahead more, than the state immediately after the move, and even this only in certain situations. It is a bit unpredictable too, thanks to some randomization. About camera - it is dynamic, not hardcoded, calculates on its own and on the fly, what is worth to show (who is moving, who is shooting, where is more units...), so we can't be sure what and how will show to us. I'm not sure, if will be possible to "convince" it for more "sense of drama". We will see. No handicaps coded. It is true, that vehicle in move may miss more often, so I added chance for some "doStop" before "doFire" for attackers. Version with magic will be, that is nearly sure, however do not know how good will work. At least part of spells may not work too well in such "unreal" and "stricted" battlefield. Other will be useless... I'll think about it. Thanks to Icewindo I have models of battlemages, used in Eight Notches mission, there are also his medieval units - how about magic and melee combat? :) Any new models will be most welcome, whatever imagination will tell you and time allows... Change here is quite easy, may be done in any moment. As for map - for now can't load any for check. Generally best would be about 2km, flat, only with very low height gradient (~1m), and very few or none view or path blocking objects... Or map, that contains such square area. One thing more - may be noted some mysterious laptop object on the table on current map. There is possibility to dispaly something on its screen via setObjectTexture command. Now I'm wondering, what this may be? Can't be any dynamic data, as this is about static texture (or set of textures)... Eg this may be mode - who is AI and who human. Any wishes/ideas?

So, if this is CTD, as in my case, then fixing this is probably beyond my skills, cause can't tell what exactly causes this and why. Do you have good PC or rather something low-end? CTD in intro/outro of Eight Notches mission and never in gameplay itself points, that there must be something about number of simultanously invoked spells, especially, that in yours case it happens far more often, with lower spell intensity. So this possible is somehow bounded with hardware capability. However, as number of particles is limited, can't tell, why overolad occurs. Because of lightsources? This is only blind guess however.

") -> )" Hmm. Also did some test with mines placed in editor and created via _mine = createMine ["MineMine", position player, [], 0]; Mines placed in the editor seems not behave as "usual" object. Its init field is not executed, can't be measured distance to it, can't be checked class (isKindOf, typeOf), naming it, eg as m1 not works... Placed such mine "thing" in editor, in init field was hint "hop". Nothing happened after preview. Then changed mine for randomly selected object (Line-keeper's box), init unchanged, this time hint was displayed. Mines created via above script seems to be something else. Distance is measured, class can be checked...

Hey, my activity here is currently dependent on the feedback. No feedback, nothing is going on. And I have other projects too, when I done with them, then probably will think about this again more, but for now not sure, in what direction should I think. Probably this dragon... I'll try to help you, but I'm not a cairvoyant. :) I never experienced any crash with this version and I need more info. How exactly looks this crash, what exactly is going on. Always, or sometimes? In what circumstancies? In all missions or in certain? Any other addons are used? Are any error logs in RPT file because of that? Best - upload here a mission, where problem occurs, if it not needs custom addons, that I haven't, then I'll be able to check this deeper. Also you may check this mission: Eight Notches If yours problem is present also there. It uses Rincewinder. And I experienced sometimes strange CTD, only during intro or, especially, outro (same in yours case?). Like somehow too many PC's resources is needed sometimes or something.

I suppose, that last part, condition, must be between "", as a string.

Great. :) No, don't think so, I'm rather mediocre player, apparently battle was conducted different way in my and yours case. HAC make things more dynamic, where these things anyway are somehow dynamic. In my case cobras and marines quickly reduced OPFOR to a half, with very low OPFOR morale of course, so there was "a risk" that they will panic and surrender before I'l have a chance to fight with them... :) In later test they manage to shot down one blackhawk and situation reversed... The truth is, that in real such operation I'll expect 3:1 attackers:defenders ratio plus many air support for USMC. For infantry would remain to sweep remnants.

So: http://www41.zippyshare.com/v/41131548/file.html Main changes: - added two triggers, that will include proper groups in proper time (plus some makeshift scripting to fix HAC's losses and morale calculations, when are included new groups "on the fly" - in the future this should be fixed inside HAC's code, if possible) - Leaders moved. B to the north, so will no die so quickly, A on the island, alas, there is no other choice. Found rather safe place for him. May be with some commands hidden, invulnerable or whatever, but must be on the island... - added one OPFOR mortar - to make things more interesting ad harder, as my proposition; - prepared OPFOR as defending island garrison. Most groups will be set around nearest objectives in defensive positions, some are "garrisoned. Will partially spread out in nearby area, occupy buildings, patrol, man static defences (if present)... See init.sqf, if not needed, or OPFOR should act offensive, just delete pointed there lines; - added invisible helipads for better insertion, will be deleted after unload; - moved some OPFOR groups from Strielka - chopper's landing and unload under fire is very unreliable; NOTE: - blackhawks under HAC control will serve as air support, cargo (teoretically) and medevac (have ambulance ability). May be a problem with landing on water after each mission (under HAC control air units will try to land at their initial positions after mission, not tested results for sea surface), so you may try to move their last waypoints over the carrier. They will go under HAC when this last waypoint will be done; - is activated debug mode; - in my opinion Cobras gives to big advantage. Unless this mission should be easy. As in Leader of B side group is armored vehicle, is some chance, that Cobra will kill Leader of B side too quickly when engaging this vehicle; - was made some other minor changes, mostly in choppers' waypoints settings; - see init.sqf for more explanations of HAC init config (what, where and why).

So I'll check yours mission. HAC is for land and air forces. Naval units are nearly complete ignored (but not cargo passengers, I believe). EDIT OK. I think, that i can fix some problems here, I would allow myself also to make some changes, only as example of course, where goal is better HAC activity. There will be also some problems. As said, Utes is too small, second thing is, that Leader can't be cutt of by water, must be present on battlefield, otherwise will be generated ugly mess, as Leader's position is important refernce point for gathering reserves etc. BTW noted some problems when including units under HAC control, this gives some mess in morale and losses calculations, if there will be no other option, I'll recommend turn off morale system for this mission. But all this later, probably tomorow.