Jump to content

Zenophon

Member
  • Content Count

    530
  • Joined

  • Last visited

  • Medals

Everything posted by Zenophon

  1. Zenophon

    [COOP-8] Black Ops

    For both of you I think at least part of the issue is this: the mission will not work when only one unit exists. This because it is relying on the leader of both groups existing in multiplayer. In SP, all AI are there and the player takes command of all of them. You need to have a least two players, human or AI, as the group leaders. I am working on a solution to this, but for now you must have two players or an AI. Speedygonzales, I would help greatly if you could post any errors that appear in the server's log. Its location depends upon how you set up your dedicated server; try something like C:\Program Files (x86)\Steam\steamapps\common\Arma 3\Server. In MP, you can also look at the log on each client to see if something when wrong there; those are at C:\Users\<UserName>\AppData\Local\Arma 3. With at least two players on a dedicated server with no AI and no JIP (all players ready at the briefing), try testing these combinations: With no mods With only mods but no changes to the mission itself With only changes to the mission With both mods and changes to the mission I am also working on getting the tasks to spawn earlier, but not such that the enemy will fire at the players as they arrive.
  2. Zenophon

    [COOP-8] Black Ops

    The mission could easily be ported to another map; there are only 8 units and 3 markers in the editor. Everything is done through scripting. I can make versions of this mission for Takistan and Chernarus, I just need to download the mod that adds those maps and get everything set up and working. Regarding mods, I haven't tested the mission with any mods, so I don't really know what their effect will be. If you try the mission with lots of mods and something doesn't work, try running with just one mod at a time to see which one conflicts. Other extensive testing with the mod or opening the mod's source code, I can't anticipate what it might conflict with or how to fix that. The mods you mentioned remind me of ACE for ArmA 2; i.e. some of the features always work for all missions (e.g. rocket backblast, weapon resting), while other require the mission be built around them (e.g. giving specific medical equipment, interacting with civilians). Without opening and editing the .pbo, you cannot. However, I can make this a parameter than be changed if you run the mission in multiplayer. I will add this when I release versions for the other maps.
  3. I did not anticipate that config values would change based upon language. The solution to this is to use a string table to substitute different text based upon the current language. Hopefully these values are in the stringtable provided by BIS. In that case it is only a matter of finding the right keys for each value. Otherwise, I have to launch the game in every language offered and look at the config values for all different kinds of vehicles. Luckily, the only function affected directly is Zen_SpawnVehicleCrew. However, I would also note that Zen_ConfigGetVehicleClasses is also using these config values to generate class lists dynamically. Every framework function that uses it to find classnames could encounter problems because the values are hard coded. To be clear, if your game language is not English, the following functions may not work for some languages with some combinations of arguments: Zen_SpawnAircraft Zen_SpawnHelicopter Zen_SpawnVehicleCrew * * Only not working for aircraft I apologize for the inconvenience; this is a beta after all. There are workarounds to using all of these functions that will work work any language. If you encounter another situation that does not work, post it and I will look at solving it specifically. Editing framework code can work, but I will offer solutions that are not internal hotfixes. That way, your mission code will remain compatible with future releases. For spawning a crew, if you know what kind of vehicle will spawn, you can hard code the classnames to fill it with: _heli = [[10,10], "I_Heli_light_03_F", 40] call Zen_SpawnVehicle; _crew = [_heli, ["i_helipilot_f", "i_helipilot_f"]] call Zen_SpawnGroup; 0 = [_crew, _heli, "All"] call Zen_MoveInVehicle; 0 = [_crew, "Crew"] call Zen_SetAISkill; Unfortunately, you would have to change the side, number, and type of the crew if the vehicle changed. Edit: I have looked at the config differences for different languages, and the issue only affects functions that are using textSingular to distinguish helicopters from jets and UAVs from UGVs. I have edited the list of functions affected. The correct localized strings are not provided by BIS's stringtable, so I need to create one to accompany the framework that will localize these three textSingular values: fast mover helicopter UAV This is nowhere near the amount of tedious work it could have been, and it will certainly be included in the release this Wednesday. Thank you for your patience.
  4. I apologize, the error is mine. In the code I posted, there is a parenthesis out of place; the if statement should have ')})' not '}))' at the end: if ((side _x == WEST) && {!(_x in _blackList)}) then { That's what happens when I don't test code. I thought these errors were always shown, but you might need -showScriptErrors in the launcher parameters.
  5. Zenophon

    [COOP-8] Black Ops

    Overview Greetings fellow Armaholics, although the advertised improvements have been somewhat delayed, I have finished work on almost everything planned and more. The mission now features a lot more content, with twice as many objectives, the inclusion of enemy vehicles and helicopters, and support options. The Google Drive link has been updated, and the Armaholic link will be soon. The most exciting addition is the new crash site objective, which breaks up the monotony of just blowing up different objects by having players save an injured pilot. There are also numerous minor improvements ranging from mission balance to optimization. The code behind the mission has doubled in length and complexity. With all of the new features in place, I have only run a few tests on a dedicated server. Everything appears to be working as advertised, but it's possible there are a few situations I did not account for. If things don't appear quite right, send me a bug report and I will look into it. Changelog
  6. I would put in the init.sqf, as it would be easier to find, change, and reuse. Also, if you decided to spawn some groups through scripting as well as in the editor, using allGroups in the editor would not include them. If you are making a multiplayer mission, I highly recommend putting the code in an if statement that only runs on the server: if (isServer) then { // ... };
  7. The variable _selectedMarker already holds a string that is a marker; it stands in for a literal string. Thus you don't need to put it in quotes: _Objective1Pos = [_selectedmarker] call Zen_FindGroundPosition; For the time, yes that is 15 to 30 minutes. The 'time' command returns seconds, so I multiply the random number by 60 to convert that to seconds. This just makes it easier to change the number of minutes directly than if I made the range [900, 1800].
  8. You can loop through every group and check if the script should be used. For efficiency, I recommend compiling the script beforehand: Zen_OccupyHouse = compileFinal preprocessFileLineNumbers "Zen_OccupyHouse.sqf"; _blackList = [group player, group Y]; { if ((side _x == WEST) && {!(_x in _blackList)}) then { 0 = [getPosATL leader _x, units _x, -1, true, true] call Zen_OccupyHouse; }; } forEach allGroups; You can use named units in the editor to get their groups and put them into the array of groups not to move. Then loop through all groups and decide based upon the side of the group and if it's blacklisted whether to garrison them. You can change 'WEST' to any side, or use '!=' instead of '==' to exclude that one side.
  9. Zenophon

    [COOP-8] Black Ops

    Glad it's working for you! It's unfortunate some mods can interfere with script-based missions.
  10. By demo I assume you mean the demonstration missions. Those are targeted mostly at intermediate level scripters. The tutorials are meant to introduce users who haven't coded a lot before to using functions. Have you fully read the first few tutorials, not just looked at the code but followed the .pdf files' explanations? The tutorials are listed in order in TutorialIntroduction.pdf in their folder. The first several tutorials show variations of what you describe. That mission should be able to spawn at most 104 AI every turn; the least it could spawn would be 48. Spawning happens at lines 299 to 312 of the init. The code to cleanup AI after an objective is done is between lines 329 and 339. Also, about half of those AI will probably be killed by the players. Every turn, only AI within 500 meters of a player remain when then next objective and patrols spawn. When players complete that objective, they are very far away from the previous one, so everything there is removed. In the worst case, 200 AI will remain (100 from the current objective and 100 from the last). However, in practice this number should be much lower. Statistically 75 AI will spawn for each objective, and less than 20 will remain when an objective is complete. If players stick together, the no-despawn area around them is only 17.4% of the total area. Of course, the code could not be working and no AI are removed. If you can, check if far away bodies and AI are really being deleted. As admin you can use the debug console and the camera to check.
  11. Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the link to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version should be on Armaholic when Foxhound sees this or I PM him. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This update has 19 changes, and I am trying to focus on bugfixes and stabilizing things. There is only one new function: Zen_GetAllInBuilding. It is fairly simple as well as tested and working. This week also sees a reorganization of some functions. This does not affect how you use any functions, nor can it break any existing mission code. The Position System, Zen_FindGroundPosition, now shares its folder with some related functions. All of the functions in what is now Position Functions category deal with evaluating terrain and similar. The index and documentation have been updated with the functions in their correct places. Zen_FindGroundPosition has also received several fixes, two of which were hotfixed shortly after release. I apologize for the issues, and I am trying to make releases with as few issues as possible. To accompany the new Position Functions category, Zen_IsNearWater has been renamed Zen_IsNearTerrain and offers options to check for land, water, or both within an area. If you have used Zen_IsNearWater directly in your mission, you need to update it to comply with this change. As always, I would remind users that legacy code and deprecated functions are not supported. The most significant optimization this week is for Zen_SpawnMarker, which now no longer checks if the marker it is creating already exists; this makes it about ten times faster. It is impossible to create a duplicate marker because Zen_SpawnMarker can generate markers with 121^10 (that's 672,749,994,932,560,068,608 or over 672 quintillion) unique names. Zen_FindMaxTerrainSlope is also twice as fast when the radius is less than 60 meters by checking fewer times. The larger the radius, the higher the distance between points to check. There was also an issue reported in which a convoy would spawn with some damage to the vehicles; two changes have been made to prevent this, but the issue might be in Zen_SpawnConvoy itself. I will continue to test and look into this issue. 8/6/14 Roadmap Due to coding other things, fixing bugs, and extensively testing things that were in fact not bugs but engine issues, the functions Zen_IsHillArea and Zen_IsUrbanArea have been delayed once again. However, I am fairly certain how to go about coding both of those, so I will try to get them finished and debugged by next week. The next significant feature I want to add is one I have been thinking about for a long time: a preprocessor library to accompany the framework. It would offer constants that could substitute for function arguments, e.g. a constant for Zen_ArraySort to sort markers by size. There would also be function-like macros that took arguments to simplify or automate common actions, e.g. appending to an array. However, before I get to coding the macros, I need to have a good plan for incorporating this into the current framework organization and usage structure. It will probably have to be done in such a way that you can choose to include the library header or not in your functions. I still have not decided if it should be split into multiple header files. If you have any ideas for good macros or how to seamlessly include this feature, feel free to send me your thoughts. Function Spotlight As users of my framework know, there is an enormous number of functions at your disposal. The amount of documentation that has to be sifted through can be extremely daunting. Each week I spotlight a function and talk about its usefulness. If you have found an obscure function (not in tutorials, barely seen in demonstrations or sample missions) that you found useful, PM me and I can spotlight it. The function chosen for this week is: Zen_ShowHideMarkers. This function automates all remote execution in multiplayer for manipulating who can see markers. Instead of trying to run different code on every client's machine, you can now just list the player objects. This is useful in PvP missions and large co-op missions where different groups of players do not share the same objective or see the same markers. For example, if you had two groups of players operating separately, you could hide certain details from the other group: 0 = [["mkCache0", "mkCache1", "mkCache2"], group A, group B] call Zen_ShowHideMarkers; 0 = [["mkCrash", "mkPow", "mkOfficer"], group B, group A] call Zen_ShowHideMarkers You could also simulate one side getting UAV support in a PvP mission: _opforGroups = [east] call Zen_ConvertToGroupArray; _opforMarkers = []; { _marker = [_x, "", "colorOpfor", [1, 1], "o_inf"] call Zen_SpawnMarker; 0 = [_opforMarkers, _marker] call Zen_ArrayAppend; } forEach _opforGroups; 0 = [_opforMarkers, west, east] call Zen_ShowHideMarkers; This makes giving certain markers and information to one side very simple. By switching east and west, you can get the opposite effect. All of this works without knowing how many players are on which side or what their names are etc. Beta As already stated, the framework is in the beta stage of development. I am making every effort to quality control releases, but there will be bugs. Both new features and old ones could have bugs, issues, and things people just don't like. There is no ETA or plan for a 'final' version. The framework is a work in progress, and it will continue to progress while there are improvements to be made (there always will be). Feedback As expected, some of the bugs have been pointed out by users, and those fixes are included in the changelog above. I want to thank everyone who has used/supported the framework. The specific request this week is: the preprocessor library. As I said before, I want to hear all ideas about what sort of things could be included to make using the framework easier. If you have code that you repeat a lot with a few differences, or arguments you always use with a function to do something, send me your idea and it can become a macro.
  12. Zenophon

    [COOP-8] Black Ops

    First, are you running any mods? Try running without any addons. Second, are you running in singleplayer, dedicated or local multiplayer? Third, have you un-pbo'd the mission and changed anything? Fourth, do any errors appear? See the log here (Windows 7) C:\Users\<UserName>\AppData\Local\Arma 3.
  13. If you are using it in the init.sqf, then you need to get the name of the objects. For units placed in the editor, you can name them anything then use that to refer to the object. So if you placed a group of units and the leader object had the name 'X': 0 = [getPosATL X, units X, -1, true, false] execVM "Zen_OccupyHouse.sqf"; Each building position is removed as it is used, so units should not be spawning at exactly the same position. However, if a building has two positions very near each other, then two unit might end up looking out the same window. Sorting all the positions by which are nearest every time a unit is placed would significantly increase the processing time of the script for large buildings. This could be a bug though, so if you can tell me what map and the coordinates of the building I will test it further.
  14. That sample mission is designed to work only with AI enabled; the same is true of Zen_InfantryPatrol.Altis, as they were already fairly complicated. They are meant to show users how to combine what is shown in the JIP demonstration with a mission. That demonstration does not mention how to get everything working when there are no AI. For how to set up JIP with no AI, see the Zen_AssaultFrini.Altis sample mission. The mission content is purposefully simple, as the only goals are to show respawn and JIP with an unknown number of humans joining at any time. Also, you can download and open the two missions I have released that use the framework (links in my signature). They both handle both enabled and disabled AI by detecting if a player took over an AI or is a new object. P.S. Thank you for your kind words, it feels great to know I am helping other mission makers do their best work.
  15. Here is how I would set up a sector control style objective for multiple towns. This code is aiming for efficiency and adaptability. I also included side missions based upon a timer. This is tested and working on Altis. It spawns enemy groups in towns when the players get close, and updates the color of the marker if a town is clear. // These constants make it easy to change every occurrence of the value later #define ENEMY_SIDE east #define AI_SKILL "Infantry" // First we get all towns, hopefully this works for the Chernarus config // You might need to tweak what the location names are _townMkArray = [["NameCity", "NameVillage"]] call Zen_ConfigGetLocations; { // You can also make them checkered/striped etc. with different commands _x setMarkerColor "colorRed"; _x setMarkerAlpha 1; _x setMarkerSize [200, 200]; } forEach _townMkArray; // Schedule the first side objective _sideObjTime = time + (60*([15, 30] call Zen_FindInRange)); // Holds arrays of groups in each town _townPatrolsArray = []; // Holds all the markers where AI have been spawned // _townMkArray is now all markers where AI have not spawned _townMkArraySpawned = []; // Assume the only Blufor units are the players _players = ([west] call Zen_ConvertToObjectArray); // Infinite loop that runs every ten seconds while {true} do { { // Only spawns patrols if at least one player is within 700 meters if !([_players, getMarkerpos _x, [700, 700], 0, "Ellipse"] call Zen_AreNotInArea) then { // Holds groups that patrol this marker _groupsArray = []; // Spawn 2 groups per marker for "_i" from 1 to 2 do { _spawnPos = [_x] call Zen_FindGroundPosition; _enemyGroup = [_spawnPos, ENEMY_SIDE, AI_SKILL, [4,6]] call Zen_SpawnInfantry; 0 = [_groupsArray, _enemyGroup] call Zen_ArrayAppend; }; // Equip and patrol the units in their marker 0 = [_groupsArray, ENEMY_SIDE] call Zen_GiveLoadout; 0 = [_groupsArray, _x] spawn Zen_OrderInfantryPatrol; // Update the spawned and not spawned arrays 0 = [_townPatrolsArray, _groupsArray] call Zen_ArrayAppend; 0 = [_townMkArraySpawned, _x] call Zen_ArrayAppend; _townMkArray set [_forEachIndex, 0]; }; } forEach _townMkArray; // Remove towns where AI have spawned _townMkArray = _townMkArray - [0]; { // _townMkArraySpawned lines up with _townPatrolsArray // _groupsArray is the array of groups patrolling the current town _groupsArray = [(_townPatrolsArray select _forEachIndex)] call Zen_ArrayRemoveDead; // Checks if the enemy is gone or dead if ([_groupsArray, _x] call Zen_AreNotInArea) then { _x setMarkerColor "colorGreen"; // 0 the indexes for this town _townMkArraySpawned set [_forEachIndex, 0]; _townPatrolsArray set [_forEachIndex, 0]; // Anything else to be done upon clearing the area }; } forEach _townMkArraySpawned; // Remove cleared towns from the arrays _townMkArraySpawned = _townMkArraySpawned - [0]; _townPatrolsArray = _townPatrolsArray - [0]; // Check if the clock is past when the side objective is scheduled if (time > _sideObjTime) then { _playerCenter = _players call Zen_AveragePositions; _objPos = [_playerCenter, [400, 700]] call Zen_FindGroundPosition; // Create the objective and reset the timer 0 = [_objPos, _players, ENEMY_SIDE, "Box", "Eliminate"] call Zen_CreateObjective; _sideObjTime = time + (60*([15, 30] call Zen_FindInRange)); // Spawn and patrol a few guards _objGuards = [_objPos, ENEMY_SIDE, AI_SKILL, [3,4]] call Zen_SpawnInfantry; 0 = [_objGuards, _objPos, [10, 75]] spawn Zen_OrderInfantryPatrol; }; sleep 10; }; Unfortunately, due to a bug in Zen_ArrayRemoveDead, the check for the marker being clear of enemies will not work. This issue is already fixed internally and will be included in the release tomorrow. If you want to test it fully today, replace this line: _groupsArray = [(_townPatrolsArray select _forEachIndex)] call Zen_ArrayRemoveDead; with this: _groupsArray = [([(_townPatrolsArray select _forEachIndex)] call Zen_ConvertToObjectArray)] call Zen_ArrayRemoveDead;
  16. This should work fine for AI local to the server. You would not want to remove the isServer check because every client would run the function and do unnecessary work. Some of the commands on the units could work remotely, while others won't, leading to strange results. In general, the function should be executed where all the units are local, so if you use it on a group of players, some things may not work (like units facing the right direction). The script was designed to handle AI only groups on whichever machine they are local to.
  17. Since 'ShapurGp' is already a group, you do not need to use the 'group' command. Try this: _nul = [(getMarkerPos "GrpM"), units ShapurGp, 100, true, false] execVM "files\Zen_OccupyHouse.sqf"; // or _nul = [(getPosATL leader ShapurGP), units ShapurGp, 100, true, false] execVM "files\Zen_OccupyHouse.sqf"; In the second usage you must directly get the position of the leader. You only need 'group' to get the group of an object; 'units' can be used on just an object as well. I use 'units group' together in the usage example for clarity. https://community.bistudio.com/wiki/group https://community.bistudio.com/wiki/units
  18. This is a bug that made it into the release version. It is not any issue with any mission (although StealTheCar has a typo of an extra ']' on line 76 of the init.sqf) but with Zen_FindGroundPosition. Due to the severity of this issue, a hotfix version has been released. Just download the latest version from the Google Drive mirror. Sorry for any trouble, I should have tested everything better.
  19. Summary Greetings fellow scripters, by user request I am adding a new feature that allows the script to fill multiple buildings differently. As a parameter, you can now choose to evenly distribute units between all the buildings in the radius, or continue to use the method of filling each building completely one by one. Also, putting units on roofs has been improved so that the script only places them at the edge. The new features have a minimal performance impact, and optimizations have been made where possible. For the typical small building with no roof positions, the time will not have changed very much (20-50ms). Of course, increasing the size and number of buildings and adding more units will add to this time. Also, giving a ridiculous radius of e.g. 1000 meters will result in about a half-second wait as the script tries to process each building. The new version is already hosted on Google Drive, and will be on Armaholic soon. All relevant sections of the original post have been updated. Changelog 7/31/14 Added: Parameter to cycle through each building in the radius, giving units to each one Improved: Units on roof are only placed at the edge, and face the edge Improved: Optimized roof check Improved: General script cleanup
  20. Introduction Greetings fellow scripters and Armaholics, in this latest installment, I will continue to discuss the development of the framework and, of course, shamelessly advertise the framework in any way possible. If this sounds boring, you can download the latest version from the original post. As always, the link to Google Drive for the .7z and .zip versions are already up to date. For those looking for older versions, go to file>revisions. The new version should be on Armaholic when Foxhound sees this or I PM him. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This update has 27 changes, just two more than last week. The most important change is a new function: Zen_IsForestArea. This is the second new function, but it was meant to be joined by a few more that I promised. Unfortunately, the algorithm for Zen_IsForestArea and its companion functions is a bit of a grey area. The next important item is a renaming, the first to appear in public releases. That which was Zen_ConfigGetTowns is now Zen_ConfigGetLocations. Its parameters have also been changed, and it now requires one argument. I apologize for the inconvenience, but as explained in the FAQ, I will make no effort to support legacy code. It only takes 5 minutes to update your mission to use this correctly. While some things seem unimportant now, the framework tries to look to the future, so Zen_ConfigGetVehicleClasses now has a parameter (optional) for including/excluding DLC vehicles and units. Unless you really love/hate the karts, it's not that interesting at the moment. There are also 8 bug fixes, ranging from removing debug (which is always cryptic and annoying) to getting the AI to cooperate with Zen_MoveInVehicle. There were issues with AI stopping and getting in/out trying to sort themselves in the vehicle, but no more; they have been convinced that they should stay in their seats. As always, the argument checking bugs are not extinct yet, but Zen_AreUnitsTasksComplete is free of them. Zen_OrderInsertion is currently being worked on; the current changes improve behavior when the crew of the vehicle are the ones being inserted. Internal testing still intermittently shows some issues, so more work must be done to get that situation working 100%, especially with boats. In both the fixed and improved categories this week is Zen_FindGroundPosition, which is more than entitled to its five changes considering its size. The bug fixes solve some issues with positions around an object that somehow survived this long. I am also in the process of making major optimization improvements in situations where failure is certain. Previously, giving impossible filters resulted in 1000 iterations and a generic error. This release, roads and water are screen beforehand to make sure they are possible, and the number of iterations scales with the given area. A tiny 20x20 marker will only try a few dozen times before stopping, while an area spanning several kilometers will still use the full 1000 limit. Zen_FindGroundPosition will also print a friendly error when the position is off the map (in the black), but it will not stop you from using that position. The loadout functions seem to make their way into the changelog every week, this time with minor improvements to taking off units' NVG's during the day. They will still be in inventory in case players need them during a 2-3 hour mission. Finally, Zen_SetAISkill reduces AI accuracy at night, because it is hard to aim in the dark or with NVG's due to the lack of color and contrast. This should make night firefights more fun by not giving the AI an advantage over players. 7/30/14 Roadmap Looking to next week, the functions meant to accompany Zen_IsForestArea are planned. I hesitate to say it is certain, so I'll just say it's inevitable that they get done eventually. Also I plan on another new function: Zen_GetAllInBuilding, which will do what you think. I am also going to continue optimizing Zen_FindGroundPosition, with changes to some of the smaller functions it uses and more screening for impossible situations. As stated in the changelog section, Zen_OrderInsertion will improve so that it always works when the crew are inserting themselves. Although the roadmap looks pitiful this week, most of the changes come along serendipitously during testing and development. Do not fear that I will run out of things to add, change, and improve. Function Spotlight As users of my framework know, there are an enormous number of functions at your disposal. The amount of documentation that has to be sifted through can be extremely daunting. Each week I spotlight a function and talk about its usefulness. If you have found an obscure function (not in tutorials, barely seen in demonstrations or sample missions) that you found useful, PM me and I can spotlight it. The function chosen for this week is: Zen_AveragePositions. This function will return the 2d average of all the objects, positions, groups, and markers that you give it. It is ideal for situations when you need to find a good compromise positions, such as a supply drop to a group of player spread out across an area. Its most impressive feature is that it accepts an effectively infinite number of arguments. You can collect an array of objects any way you want, then find their center with one line. Here is an example: _townCenter = (nearestObjects [getMarkerPos "mkTown", ["house"], 100]) call Zen_AveragePositions; This will return the center position of the town by averaging all of the houses. You can also make use of other framework functions to get the objects or positions: _unitsCenter = (["mkTown"] call Zen_GetAllInArea) call Zen_AveragePositions; _unitsCenter = ([east] call Zen_ConvertToObjectArray) call Zen_AveragePositions; The first one will get the center position of all the units in the town, and the second will give the average of all Opfor units in the mission. Now, what might you do with such a center position? You can use it to make your code react to the distribution of objects in an area. You could use fire support in the area of town near the Opfor, or call for an insertion of players to an LZ away from Opfor patrols. If you want to see how close the average is to all the units, try using Zen_FindMaxDistance and Zen_FindMinDistance. Beta As already stated, the framework is in the beta stage of development. I am making every effort to quality control releases, but there will be bugs. Both new features and old ones could have bugs, issues, and things people just don't like. There is no ETA or plan for a 'final' version. The framework is a work in progress, and it will continue to progress while there are improvements to be made (there always will be). Feedback As expected, some of the bugs have been pointed out by users, and those fixes are included in the changelog above. I want to thank everyone who has used/supported the framework. The specific request this week is: randomization. I would like to hear how you randomize and create replayability in your missions and scripts. This is one of the primary features and goals of the framework, and one of the things that really separates it from the editor. Thus, I am interested in how you are using random positions and random spawning to keep things interesting.
  21. I see what you mean now...this is not that hard to do. It would either be completely random, with no preference given to any building, or rotate through all the buildings, giving one unit to each in turn. It will also probably be a parameter, as some users might prefer to be more certain about which buildings the units will fill. I'll try to think of some other improvements as well; a changelog with just one item looks somewhat sad. Something like checking that units are on the edge of a roof so they can shoot down.
  22. I don't know which garrison script you mean, there have been several made over the years. I will highlight why I think my script is unique: It does not spawn any units It only places units at windows they can see out of It has an option for putting them on the roof You are in control of which buildings it fills No, but here is a five step guide to using it: Open a new mission in the editor and save it Put the script in the mission folder Place a group (F2) near a building (Optional) Make the group leader the player Copy this into his init: 0 = [getPosATL this, units group this, -1, true] execVM "Zen_OccupyHouse.sqf"
  23. 1. Use compile instead of compileFinal, e.g.: SomeFunction = compileFinal preprocessFileLineNumbers "SomeFunction.sqf"; // or SomeFunction = compile preprocessFileLineNumbers "SomeFunction.sqf"; You can't change the init.sqf during a mission because it is hard-coded and preprocessed and compiled once at mission start. You can run it again though: https://community.bistudio.com/wiki/runInitScript You can also just use a proxy init function, e.g. Init2.sqf, that is not compiled finally. 2. This depends, if the functions are just SQF commands that used to be all together, then the only overhead to using call is that engine has to define a lower scope. However, if all those functions check arguments, print debug, etc. something that was previously done once, the time can add up if they are called a lot. For what that lower scope overhead is, try this: f_append = { _array set [_i, _i]; }; _array = []; _sTime = diag_tickTime; for "_i" from 0 to 10000 do { _array set [_i, _i]; // call f_append; }; _eTime = diag_tickTime; player sidechat str (_eTime - _sTime); I get 66.8ms seconds with just 'set', and 127.ms with the function. Also note the function uses the variables directly; it would take more time if arguments were passed. However, the percent increase of the overhead time will decrease as more commands are added. You probably won't see a significant difference if you call a 100 line function vs. run the code directly. 3. I assume so...unless the engine has some internal methods that are not in the SQF API. However, I recall that the wiki claims that cfgFunctions are compiled with compileFinal. Somewhere here: https://community.bistudio.com/wiki/Functions_Library_%28Arma_3%29
  24. I agree that that would slow down the thread a lot, but the engine would still have to move on to the next thread in 3ms. Are you saying that something like that will make the engine break the 3ms rule? How would it interfere with other threads other than taking the full 3ms its thread is allowed? It's true commands like that require more processing and thus have a performance impact. If one thread reduces the framerate the engine can calculate/render at then all threads slow down. However, a loss of 5 or even 10 fps is not that much out of 50 fps or so. Some commands seem to freeze the engine until they can be processed though, e.g. simulWeatherSync. I assume this is done because they need more than 3ms? Anyway, isn't most of this theory based upon experiments using lots of simple commands, e.g. KK's tests. The execution time of one small command e.g. 'distance' is too short for the accuracy of diag_tickTime to measure. What exactly is the difference when we using a scripting command that is essentially a very complex engine-based function. Do the results of using nearObjects with a radius of 10,000 meters still support the 3ms rule?
  25. Thank you for correcting me, as I was still thinking with old information. I am very certain that the wiki page you linked actually used to say .3ms per command; however, I see this was a misconception that arose from benchmarking frames and engine time. It seems possible that in ArmA 2 with older hardware that some scripts executed 10 times per frame, thus the .3ms myth. The last part of KK's blog that you linked shows why trying to reduce the delay to Xms/command does not work. In those 3ms, his experiment code executed an average of 205 times per frame, giving .015ms/command. This is not a fixed number, and is actually Xms/command/thread. So increasing the number of lines/frame that execute in 3ms is the determining factor in how many frames a script takes to run. Now the question: how many threads can reasonably run every frame? At 60 frames/s => 16.7 ms/frame => 5.56 threads/frame at 3 ms/thread. I assume anything more than that can delay the scheduler. Applying this to waitUntil loops, you could have 5 waitUntil loops taking the full 3ms allowed without any performance impact. Any threads that take less than 3ms subtract linearly from the 16.7 ms/frame, so you could have dozens of threads execute a few commands every frame. Also, every thread can expect to be suspended for 16.7 ms. All of this is apparently independent of the length or complexity of those threads. That only matters for how long a thread is running. Very interesting, and it's all part of the fun of SQF and ArmA.
×