Zenophon

Member
  • Content count

    505
  • Joined

  • Last visited

  • Medals

Community Reputation

83 Excellent

4 Followers

About Zenophon

  • Rank
    Gunnery Sergeant

Profile Information

  • Gender
    Male
  • Location
    'Murica
  1. Update and Release #51 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 links 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 will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This release falls on the third anniversary of the framework's first release; thusfar, I have counted 806 total changes to the framework. I am truly grateful for all of the comments and suggestions that allowed for so many fixes, improvements, and additions. The vast majority of what I had planned to do is finished; I will continue to maintain the framework with bugfixes and small improvements. Added in this release is Zen_ArrayRemoveType, which is basically the remove version of Zen_ArrayGetType. This might be a useful shortcut instead of writing a code condition for Zen_ArrayFilterCondition; it also searches recursively and should be slightly faster. Now that BIS have allowed ctrlCreate to use control classes defined in the mission's .ext file, the dialog system can take advantage of that to be on truly equal footing with tradition dialog creation. Zen_InvokeDialog will look for the type of defined control and apply properties appropriately (e.g. types 1, 11, 16, and 41 are considered buttons). The template subsystem is now tied into the action system, with Zen_CreateTemplate and Zen_SpawnTemplate being able to copy-paste existing actions onto the new objects. This greatly reduces the hassle of manually applying your actions to the correct spawned object. 7/10/17 New Function: Zen_ArrayRemoveType Fixed: Zen_ExtendVector did not use relative height if its second argument was a vector Fixed: Zen_RefreshDialog did not remove controls properly in some cases Improved: Zen_CreateControl now allows mission defined control classes as the first argument Improved: Zen_CreateTemplate and Zen_SpawnTemplate now copy actions added using the framework's action system Documentation: Added for Zen_ArrayRemoveType Documentation: Updated Notepad++ SQF language and autocompletion file with ArmA 1.72 stable commands
  2. The framework's task system appears to fail when all objects assigned to a task are deleted (like when the players leave) because it automatically deletes tasks for which there are no units. This is done because there is no direct command to remove the data entry itself, only units that have the task. This is most likely the issue if you are testing the JIP code alone by joining, leaving, then joining your persistent server with team AI disabled. To account for this, you need to manually create a proxy unit that will hold the task for players. Any invisible/disabled proxy AI unit (preferably local to the server) somewhere on the map will work; you would include this unit with the players when you use Zen_InvokeTask (or you could use Zen_ReassignTask to this unit when some players still exist). You can then use Zen_ReassignTask normally for this task on JIP players.
  3. Update Overview Greetings fellow Armaholics, this release ports appropriate missions to Tanoa, for a total of 45 variants on 9 maps. Changelog 6/17/17 1. Added: Fatigue parameter for all missions Abduction 1. Added: Tanoa version Ambush 1. Added: Tanoa version Checkpoint 1. Added: Tanoa version Convoy 1. Fixed: Removed debug markers (Takistan version) Sweep 1. Added: Tanoa version
  4. Update and Release #50 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 links 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 will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This release introduces a major addition to the framework, a system for managing actions. It currently uses ArmA's traditional action menu, since it is simple and doesn't seem to going anywhere. There are several benefits of this system; you no longer have to write your own functions for adding and removing actions, all MP synch'ing is done for you, and adding actions to JIP client is much easier. All framework functions and documentation have been updated to take advantage of this new system. This now allows you to interact with actions added by framework functions; you can add and remove them manually during the mission. All framework actions now have a global variable stated in their the function's documentation. The JIP demonstration and all sample missions that implement JIP have been updated. The updating of actions and the usage of many framework action functions has changed. Also of note is another new function, Zen_ArrayTranspose. This function makes a two dimensional transpose of an array, which means it leaves nested, nested arrays and lower intact. It is mainly intended for transforming data structures to separate a list of properties from their assigned identifiers. ZEN_FMW_Code_GetRemoteVarArray and ZEN_FMW_Code_GetRemoteVarArrayT have been added to make remote access to such data structures easier. In order to provide the greatest possible performance increase to the dialog system, Zen_RefreshDialog now allows the user to optimize the refresh process for their specific dialog/refresh. You can now specify which controls to force refresh (without checking for changes, i.e. you know there were changes), which to ignore (i.e. you know there were no changes), and which to check and update normally (the remainder from those two arguments). This allows you create separate, efficient refreshes for different parts of your dialog, massively speeds up refreshing of large text blocks (e.g. cycling pages of text), and improves the users' experience. 5/24/17
  5. There's nothing wrong with your code or the arguments to Zen_OrderVehiclePatrol. After testing a lot of different possibilities, the fix for this is a simple 'doMove' command added to the existing 'move' and 'addWaypoint' commands in Zen_OrderVehiclePatrol. Testing a large sample (30 vehicles) without 'doMove' gives about a 60% compliance rate; adding doMove makes it 100%. I cannot explain why 'doMove' works when 'move' does not; repeating the 'move' command does not always work. Various other factors (vehicle type, side, the method for spawning the crew, checking if the vehicle has complete a move order) have no effect on this as far as I can tell. This fix will be duplicated to various other Orders functions for the next framework release (which should be in about a week, as I'm finishing up some new things). If you want to modify Zen_OrderVehiclePatrol yourself, just add (driver _veh) doMove _mpos; as lines 60 and 93 after the 'move' line.
  6. You are correct, publicVariable does say you don't need to manually publicVariable anything to JIP clients, if the latest value has been PV'd previously (which is the case with your code). I don't remember if I every tried using this when I was creating my JIP code. I probably just did it manually to be certain it would work. This is somewhat a case of 'trust but verify'. publicVariableClient must be run on the server; it's essentially repeating the automatic synch'ing that PV should already have done. Note that variables that are not always PV'd from the server at every update (i.e. a 'server-side' variable that is not guaranteed to be up to date on a client) do require this (e.g. the catch-all Zen_JIP_Args_Server). You're using the variables as global rather than server-based, but this is an alternate style. I cannot reproduce this; can you post the exact arguments you gave the function? It might be an issue with how the function is interpreting the patrol area (e.g. giving the vehicle a destination it cannot reach). Also, there are issues with AI simply not obeying a move order, but I've never been able find a cause for it. You could also try adding more vehicles, if none of them move, it's not just random AI confusion. The type, side, etc. of the vehicle should have no effect on the result (you can even mix vehicles of different sides).
  7. Detecting that a client in JIP should be done correctly by the framework; it will give you the _Zen_Is_JIP boolean in the init. It will also wait for the player to initialize before compiling the framework. Task1 is undefined because running publicVariable only sends the variable to current clients. The JIP client doesn't have this variable defined, or any of the information it needs when it starts. Zen_SyncJIPServer is given as a template in the JIP demonstration to show how to the JIP client 'asks' the server for the information it needs, but you must define it in your mission and customize it. For example, in your mission it could include (owner _this) publicVariableClient "Task1"; Once the waitUntil is over, the JIP client can use that variable. Also, using Zen_ReassignTask assumes that the JIP player's object did not previously exist. That means that other clients have no information about it either; thus, every client must be updated with the tasks of the new object. If you've disabled friendly AI, then using Zen_ReassignTask is correct. If the player object did exist (as an AI), the JIP demonstration shows how to use the private function Zen_InvokeTaskClient to update tasks. There is a mistake in the JIP demonstration with Zen_InvokeTaskClient; the line should end with '(_x select 6), (_x select 8)] call Zen_InvokeTaskClient;', since tasks now support different icons. The error doesn't stop tasks from working though.
  8. Update and Release #49 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 links 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 will be on Armaholic soon. Please bring any technical issues or mistakes to my attention, so e.g. people don't download the wrong version etc. Changelog This release focuses mostly on the dialog system. The first important addition is support for control eventhandlers provided by the engine using the Event property; the full list is in the documentation. The arguments of the EH will be passed, along with the standard arguments from data and linked controls; there is no limit to the number of events that can be stacked. For the arguments and exact behavior of each EH see the BI wiki (https://community.bistudio.com/wiki/User_Interface_Event_Handlers). Note that only EH's for controls are handled through this property; display EH's for the whole dialog must be added manually to (findDisplay 76). The code behind Zen_RefreshDialog has been improved and updated to fix some issues and provide a smoother user experience. It no longer resets which item in a list the user had selected; note that this is tracked by index only, if you rearrange elements of the list the selected value will change. Zen_RefreshDialog also supports a variable update time, for smooth transitions between values. I will be working on further optimizations in the future to improve the response time of Zen_RefreshDialog. The map control can now be manipulated using the MapPosition and MapZoom properties; this allows you to scroll the map in response to user actions. An important note: because the user can manually move/zoom the map, the MapPosition/MapZoom value of a map control is not necessarily the true; in order to restore the position/zoom of the map, that value must have changed in the control's data before you use Zen_RefreshDialog. That means that you need to slightly change the position, e.g. with (vectorAdd [random 5, 0, 0]); otherwise, Zen_RefreshDialog will not know that the control requires updating. A new StructuredText control type is supported; this control uses parseText on the regular Text property to interpret HTML/XML-like codes in the text. Refer to the BI wiki (https://community.bistudio.com/wiki/Structured_Text) for the formatting of such strings. Zen_InvokeDialog now has a parameter to catch the Esc key and prevent it from closing the dialog. Warning: this will lock the user into the dialog and prevent them from closing it or exiting the mission; if the dialog does not provide another way to close it, the user will have to Alt-F4 out of the game. 4/18/17
  9. The "Vehicle is of unknown vehicleClass type" is just a warning that did not recognize the type of vehicle and spawned the default rifleman as the crew (b_soldier_f, etc.) rather than a tank crewman, helicopter pilot, etc.. There should still be a crew in the vehicle. For example, these lines _rhs_veh = [player, "rhsgref_ins_g_btr70"] call Zen_SpawnVehicle; 0 = [_rhs_veh] call Zen_SpawnVehicleCrew; produce the error but result in a working vehicle. You can use Zen_GiveLoadout and similar to change the crew's appearance, or as cdn_biggdogg said use Zen_SpawnGroup/Zen_SpawnInfantry and Zen_MoveInVehicle. The Generic error in expression at 'sleep' looks like the result of running in an unscheduled environment. If you're using the function from an EH, you'll need to use 'spawn' to get a scheduled environment. This is discussed the FAQ. Since the usage of addon vehicles/units is much more prevalent than when I wrote Zen_SpawnVehicleCrew, there's no reason the function can't keep up with the times. For the next release (for which it's about time), Zen_SpawnVehicleCrew will use the classname defined in the vehicle's config under 'crew' ("rhsgref_ins_g_crew" in the case of this BTR-70). That will allow it to automatically spawn addon units that fit their vehicle; if a vehicle lacks this property or the user gives a side that disagrees (so you can still force e.g. Blufor in a FIA truck), the old method will be used. I'll put the names of the class properties into the function's description. Unfortunately, it's easy to miss the FAQ file; it's an odd combination of general questions and a few important details (class properties and the scheduled environment mainly).
  10. You mean a one-way insertion that waits for the players to get in the helicopter? As an example, I cut this out of the Abduction mission from ZMCM: _heli = ["mkBase", "b_heli_transport_01_f", 0, random 360] call Zen_SpawnHelicopter; waitUntil { sleep 2; ([_players] call Zen_AreInVehicle) }; _h_insert = [_heli, [_lzPos, "mkBase"], _players, "full"] spawn Zen_OrderInsertion; How you determine _lzPos is based upon the mission; it could be random, given by player input, etc. A self-contained function for that is not provided by the framework, but the logical parts required to do it are. You can use Zen_GetAllInArea to find the units inside the marker, as well as Zen_AreInArea and Zen_AreNotInArea to check for specific units being inside. The exact logic of the script depends upon what you consider to be 'conquered' as well as if the Opfor can recapture the zone, but for as a simple example of one-time capture // let's call it "mkTown" waitUntil { sleep 2; (count (["mkTown", [], east] call Zen_GetAllInArea) == 0) }; "mkTown" setMarkerColor "colorBlufor"; If you are using the task system, the above code is basically the same logic as that of Zen_TriggerAreaClear. Using the config viewer in the editor, 5, 6, and 8 would be 'vehicleClass', 'faction', and 'expansion' data fields. Note that units are sorted and categorized in the editor based upon these, so e.g. all the Apex guerrilla units share the same 3 values (and thus are all in the same unit submenu). You can also make use the blacklist argument to exclude any units from that set you don't want. The code for those Apex units would be: _group = [_pos, resistance, "infantry", [3,4], "Men", "IND_C_F", ["I_C_Soldier_base_unarmed_F", "I_C_Pilot_F"], "Expansion"] call Zen_SpawnInfantry; where we've left out the unarmed unit and the pilot (and confusingly the expansion value is 'Expansion', but that's the value for all Apex classes).
  11. Saving in SP works for most things; all running scripts are restored and the mission will proceed as intended. There have been issues reported in the past about UI scripts stopping, addons not loading properly, etc. (which I've never seen myself), so at the time I released my framework I made a blanket statement against saving to prevent such issues in SP. I was also mostly thinking about missions written for co-op being played in SP, where saving would not be part of the mission's design (and thus not necessary in SP). If a save/load cycle works in your mission, then of course you can enable it. There's nothing built into the framework against saving.
  12. Update Overview Greetings fellow Armaholics, this latest release ports this mission to Tanoa and offers 3 new enemy factions to choose from. You can use the additional mission parameter to choose between the AAF (the default and original faction), CSAT, FIA, or Apex guerrillas. Note that if you choose the Apex faction, you'll need that DLC to scavenge enemy weapons. I've also added random DLC loadout (for both marksmen and Apex); you'll need to have the DLC in order to receive those loadouts (you'll also see the AI using them). There is now a mission parameter for fatigue, for those who want to disable that. Changelog 2/3/17 Added: Tanoa version Added: Mission parameter for enemy faction Added: Mission parameter for fatigue Added: New DLC loadouts Improved: Various improvements and fixes included in my latest framework
  13. The issue occurs in the absence of Zen_OrderAircraftPatrol, just with the simple spawning code I tested. Zen_OrderAircraftPatrol is using 'move' and 'addWaypoint'; the aircraft always goes to [0,0,0] after a move order is complete. Since Zen_OrderAircraftPatrol gives a new waypoint after that, it means that Zen_IsReady returned true for the aircraft. I don't think anything is ordering the AI to move [0,0,0]; it seems like an intrinsic bug in their AI. Instead of circling their last waypoint (or their spawn point), they forget it and go to [0,0,0].
  14. You can edit the missions if you want; just add new playable units to the existing group in the editor. Those new slots will be detected automatically by the code (and they can JIP). It's all generalized, so you could add as many slots as you wanted. I'm assuming they're all human players, so it doesn't matter that they're all in the same group; if you want multiple groups that requires some coding changes. You might find that the mission is too easy with 12 players; you can change the values of all the difficulty parameters in ParseParams.sqf. For example, in case 2 of AI strength, put '_maxIndfor = 160;'. The mission will accommodate any values you choose.
  15. Update Overview Greetings fellow Armaholics, this latest release ports this mission to Tanoa and offers 3 new enemy factions to choose from. You can use the additional mission parameter to choose between the AAF (the default and original faction), CSAT, FIA, or Apex guerrillas. Note that if you choose the Apex faction, you'll need that DLC to scavenge enemy weapons. Changelog Added: Tanoa version Added: Mission parameter for enemy faction Improved: Various improvements and fixes included in my latest framework