Jump to content
Zenophon

Zenophon's ArmA 3 Co-op Mission Making Framework

Recommended Posts

Hey Zen. I downloaded the new update and I get an error that crashes Arma to desktop that says Zen_LoadoutDialog.hpp is missing!

 

I copied the one from the last update over for now to make it work!

 

First line of description.ext has been changed to:

 

#include "Zen_FrameworkFunctions\Zen_DialogSystem\Zen_Dialog.hpp"

 

Mimir.

Share this post


Link to post
Share on other sites

First line of description.ext has been changed to:

 

#include "Zen_FrameworkFunctions\Zen_DialogSystem\Zen_Dialog.hpp"

 

Mimir.

 

Ahh...I totally missed that.....thanks

Share this post


Link to post
Share on other sites

Hi . i have no idea how to use this framework. I read the read and tutorial and i stay a dunce.

Could someone please switch on the light for me?

Share this post


Link to post
Share on other sites

Hey Zen, have an idea for the dialog system: Maybe a "Yes/No Dialog" function could be implemented that returns true or false, whould only take a string as a parameter for the message.

Share this post


Link to post
Share on other sites

Hi . i have no idea how to use this framework. I read the read and tutorial and i stay a dunce.

Could someone please switch on the light for me?

You mean you can't follow the steps in the tutorial, or you don't understand the point of the framework? The tutorials are guiding you through how to do something, so you can see what the effect is and what's possible. It's like following any walk-through or guide; it tells you exactly what to do so that you can see that effect in-game. The idea is that users see what is happening and learn what functions to use to do that. It's not necessary that you 100% understand everything that's going on; the point is that you can create some effect in-game with just the basics.

The framework is essentially a toolbox; every function is a tool. You need to use those tools on raw materials (arguments) to get some effect. Then you use the tools one after the other to build upon their effects. The first tutorial shows you that with four functions, you can create a basic playable mission. There are now 192 functions and 87 macros that each serve a purpose as a unique and useful tool. The mountain of documentation is a user manual so that people can use these tools.  What the tools do and how you use them are designed to make mission-making much easier for anyone who invests the time to learn them.

 

Hey Zen, have an idea for the dialog system: Maybe a "Yes/No Dialog" function could be implemented that returns true or false, whould only take a string as a parameter for the message.

This is a 'packaging' of functions into a higher-level function, which is of course doable, but it doesn't match the level of the dialog system. If each function was a unique dialog, there would be hundreds of them. I've chosen to include less in each function so that more are required to create a dialog; however, the functions can create hundreds of possible dialogs.

You're free to create 'wrapper' functions like that and use them; that's good programming if you repeatedly use this dialog. I just can't do that for every possible dialog, so I leave it up to mission makers what dialogs they want to wrap into a function. Here's what you're describing, but it's up to users to make this sort of thing into a function (I'll help if you ask).

F_YNEvent = {
    _YN = _this select 0;
    hint str _YN; // debug
    if (toLower _YN == "yes") then {
        //
    } else {
        //
    };
    call Zen_CloseDialog;
};

F_YNTextDialog = {
    _text = _this select 0;
    _dialogID = [] call Zen_CreateDialog;

    _controlButtonY = ["Button", ["Data", "Yes"], ["Text", "Yes"], ["Position", [15, 22]], ["Size", [5,2]], ["Function", "F_YNEvent"]] call Zen_CreateControl;
    _controlButtonN = ["Button", ["Data", "No"], ["Text", "No"], ["Position", [20, 22]], ["Size", [5,2]], ["Function", "F_YNEvent"]] call Zen_CreateControl;
    _controlText = ["Text", ["Text", _text], ["Position", [10, 20]], ["Size", [30,2]]] call Zen_CreateControl;

    0 = [_controlButtonY, ["LinksTo", [_controlButtonY]]] call Zen_UpdateControl;
    0 = [_controlButtonN, ["LinksTo", [_controlButtonN]]] call Zen_UpdateControl;

    {
        0 = [_dialogID, _x] call Zen_LinkControl;
    } forEach [_controlButtonY, _controlButtonN, _controlText];

    (_dialogID)
};

_dialog = ["Test"] call F_YNTextDialog;
0 = [_dialog] spawn Zen_InvokeDialog;

That shows another feature, controls can link to their own data.

Share this post


Link to post
Share on other sites

Update and Release #34

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

Here we have the next weekly release in support of the new dialog system. Every change is for this system, including five new functions, events for lists, and new and improved properties for controls.

There are now copy and remove operations for both dialogs and controls. Those copied controls and dialogs are entirely independent of their source. Removing a control will not unlink that control from existing dialogs, you must do that manually.

To support list events, there are now 2 (and the potential for more later) types of event functions. 'ActivationFunction' is exactly the same as 'Function' for buttons; simply copy-paste the new property name. In addition, 'ActivationFunction' will fire when a list box element is double clicked on.

'SelectionFunction' applies only to lists, and will fire when an element is clicked. It will also fire when the dialog first displays (on the first element), and twice when double clicking on an element. If you assign both types of events to a list, you must handle those extra events in your functions.

The property previously called 'TextColor' is now 'FontColor'. To standardize things, everything relating to individual characters (size, font, color, etc.) is font formatting; anything related to a text block (text, alignment, etc) is text formatting. Also, 'FontSize' is now scaled so that standard point font sizes can be entered; 12, 16, 20, etc. should be fairly close to those pt. fonts.

It is not longer necessary to link controls to themselves; a control's event will be given that control's 'Data', the 'Data' of all linked controls, the 'ListData' of the selected element of all linked lists, and the 'ListData' of the control's own selected element (if it is a list itself). This should provide better support for list events and dialogs with multiple lists. Remember, event data is passed in the order that controls were linked, with 'Data' before 'ListData' for the same control.

I have discovered an odd bug, in which the selectable line on a list never goes past the seventh item down. This is described in the KnownIssues.txt file as well. This does not prevent any elements from being selected, as the list will just scroll into some empty space. This is mostly an aesthetic bug and there is no clear fix.

Next week, I'll be adding selective control refresh to reduce menu 'blinking' on refresh and improve performance for complex dialogs, a dialog to select fire supports added with Zen_AddFireSupportAction, and more control properties for tooltips and colors.

9/17/15

  • New Function: Zen_CopyControl
  • New Function: Zen_CopyDialog
  • New Function: Zen_RemoveControl
  • New Function: Zen_RemoveDialog
  • New Function: Zen_UnlinkControl
  • Fixed: Zen_InvokeDialog did not apply 'TextColor' property to lists
  • Added: Zen_CreateControl 'Font' and 'SelectionFunction' property
  • Added: Zen_CreateControl 'Function' property renamed 'ActivationFunction'
  • Added: Zen_CreateControl 'TextColor' property renamed 'FontColor'
  • Improved: Zen_InvokeDialog passes the 'Data' property of linked lists as well as 'ListData' for the selected element to event functions
  • Improved: Zen_InvokeDialog passes the 'Data' property of the control whose event function has fired
  • Improved: Zen_CreateControl 'FontSize' property is now scaled for approximately pt. scale font inputs
  • Documentation: Added for Zen_CopyControl, Zen_CopyDialog, Zen_RemoveControl, Zen_RemoveDialog, and Zen_UnlinkControl
  • Documentation: Added known issue for list box controls in the dialog system
  • Documentation: Updated for Dialog System, POWDialog tutorial

Share this post


Link to post
Share on other sites

Update and Release #35

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

Although the changes look pitifully few, it's only because I put all the new properties on one line. Refreshing of only certain controls is a fairly large feature as well; it eliminates menu blinking for most controls and prevents lists from resetting their selection to the first element (and triggering a selection event on that element). The process of selecting which controls to refresh should have no performance impact. Also, some Notepad++ SQF language mistakes have been corrected.

I didn't include a dialog for the fire support actions, as I'm going to be making other improvements to that system. It will become an all-round support system, allowing for not just fire support, but any sort of player-called assistance or actions from the AI. I plan for mission makers to be able to plug-in their own functions and have their custom support actions show on a dialog.  It could be used in a very general way to present any event-driven action players.

Next week for the dialogs, I'm planning on doing more control types; they'll likely be drop lists and sliders.  They'll get appropriate events and as many visual properties as possible.

9/25/15

  • Added: Zen_CreateControl properties FontColorSelected, ListTooltip, ForegroundColor, BackgroundColor, Tooltip, TooltipFontColor, TooltipBackgroundColor, and TooltipBorderColor
  • Improved: Zen_RefreshDialog only refreshes controls whose properties have changed
  • Documentation: Fixed Notepad++ SQF language and autocompletion file with a few missing commands
  • Documentation: Fixed Notepad++ SQF language file showed a few commands in the wrong color
  • Documentation: Updated for Dialog System

Share this post


Link to post
Share on other sites

"After skimming through the ASR AI source code, here's what I can see. ASR AI is compatible with spawning AI through scripts during the mission. It will automatically detect any spawned soldier that is a subclass of: SoldierWB, SoldierEB, and SoldierGB (use 'isKindOf' on an object if you're not sure); then it applies the skill changes and everything else. ASR AI does not give AI groups waypoints, so it has no conflict with any framework Zen_Order... function.

However, every spawning function that spawns AI, except Zen_SpawnGroup, uses Zen_SetAISkill to set their skills. Whichever function makes the skill changes last will win out, so it just depends upon the timing. To avoid a conflict and use ASR AI's skill settings, you can only use Zen_SpawnGroup to spawn AI. That excludes Zen_SpawnAircraft, Zen_SpawnGroundVehicle, Zen_SpawnHelicopter, Zen_SpawnBoat, Zen_SpawnVehicleCrew, Zen_SpawnConvoy, Zen_SpawnInfantry, Zen_SpawnInfantryGarrison, and the 'officer' and 'pow' objectives of Zen_CreateObjective.

Your best option is to find and comment out every usage of Zen_SetAISkill in the framework. That's not as bad as it sounds, as most of those function don't call Zen_SetAISkill directly. Just put a // at the beginning of the line given for each file:

  • line 39 in Zen_ObjectiveSystem\Zen_SpawnOfficer.sqf
  • line 40 in Zen_ObjectiveSystem\Zen_SpawnPow.sqf
  • line 70 in Zen_SpawningFunctions\Zen_SpawnInfantry.sqf
  • line 150 in Zen_SpawningFunctions\Zen_SpawnVehicleCrew.sqf

That will remove all AI skill changes from the framework. You're free to use this (or any) altered version of the framework as part of any missions you release".

 

I am using yours bro. I am just going to disable the ASR_AI skills to just be safe.

Share this post


Link to post
Share on other sites

Update and Release #36

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

The highlight of this release is, of course, the dialog system with two new controls added: sliders and drop lists. A drop list, or combo box, functions just like a list box, except it lacks tooltips and double click events.

Sliders operate on integer detent positions, with the maximum given when it is created. There is no data associated with each slider position, it's up to you to do something with the position index. Sliders have position changed events ("SelectionFunction") when moving the bar; the returned bar position is always rounded to an integer when the player drags it.

I have fixed the annoying "SelectionFunction" event firing when invoking a dialog. This was due to the function automatically selecting the first element in a list. Zen_RefreshDialog wasn't getting every changed control properly, as some changed data fields were not being detected due to hashing inaccuracies.

10/3/15

  • Fixed: Zen_CloseDialog and Zen_RefreshDialog did not return void
  • Fixed: Zen_InvokeDialog does not immediately fire list selection events when called
  • Fixed: Zen_RefreshDialog did not always refresh changed controls
  • Added: Zen_CreateControl control types DropList and Slider
  • Added: Zen_CreateControl properties Picture, PictureColor, PictureColorSelected, and SliderPositions
  • Documentation: Fixed for Zen_GetControlData
  • Documentation: Fixed JIP demonstration didn't synch global dialog and control data
  • Documentation: Improved POWDialog tutorial with MP and locality section
  • Documentation: Updated for Dialog System
  • Documentation: Updated Notepad++ SQF language and autocompletion file with ArmA 1.52 stable commands

Roadmap

I'm changing the release schedule to once every two weeks once again, as most of the possible control properties are in and working. I'll be adding more control types and any more properties that look useful in future releases.

The support action system (notice I've dropped 'fire' from the name) is progressing towards offering custom supports. I'm trying to present it so that there is a good balance of flexibility and usability. However, presenting the options on a dialog requires a complete rewrite of the internal code due to MP locality.

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 release 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 think is useful, PM me and I can spotlight it.

The function chosen for this release is: The Dialog System. I've added quite a few control properties over the last few weeks, and now, with the addition of the slider and drop list control types, there isn't a good example of how to use everything.

Thus, I give you the code for my 'debug dialog' that tries to test absolutely everything. You'll need your own Test.paa texture file in order to actually run this, but it's main goal is a code reference. Also ignore Zen_HashControlData; that's in there for debugging the selective control refresh.

 

F_OKbutton = {
    player sideChat ("Button activated: " + str _this);
};

F_ListClick = {
    player sideChat ("List selected: " + str _this);
};

F_ListDoubleClick = {
    player sideChat ("List activated: " + str _this);
};

F_Slider = {
    _textID = _this select 0;
    _number = _this select 1;

    // player sideChat ("List selected: " + str _this);
    // player sideChat str ([_textID] call Zen_GetControlData);
    // player sideChat str ([_textID] call Zen_HashControlData);
    0 = [_textID, ["Text", "Hello " + str _number]] call Zen_UpdateControl;
    // player sideChat str ([_textID] call Zen_GetControlData);
    // player sideChat str ([_textID] call Zen_HashControlData);

    0 = [] call Zen_RefreshDialog;
};

_dialogID = [] call Zen_CreateDialog;

_controlButton = ["Button",
        ["Text", "OK"],
        ["Position", [0, 0]],
        ["Size", [5,2]],
        ["FontSize", 12],
        ["Tooltip", "OK button"],
        ["TooltipFontColor", [0, 0, 100, 255]],
        ["TooltipBackgroundColor", [0, 100, 100, 255]],
        ["TooltipBorderColor", [100, 100, 100, 255]],
        ["ForegroundColor", [100, 0, 0, 255]],
        ["BackgroundColor", [0, 100, 0, 255]],
        ["ActivationFunction", "F_OKbutton"]
    ] call Zen_CreateControl;

_controlButtonRefresh = ["Button", ["Text", "Refresh"], ["Position", [0, 2]], ["Size", [5,2]], ["ActivationFunction", "Zen_RefreshDialog"]] call Zen_CreateControl;
_controlButtonClose = ["Button", ["Text", "Close"], ["Position", [0, 4]], ["Size", [5,2]], ["Font", "PuristaBold"], ["ActivationFunction", "Zen_CloseDialog"]] call Zen_CreateControl;

_controlText = ["Text",
    ["Text", "Hello, 0"],
    ["Position", [0, 6]],
    ["BackgroundColor", [0, 100, 0, 255]],
    ["Size", [5,2]]
] call Zen_CreateControl;

_controlSlider = ["Slider",
    // ["Text", "Hello"],
    ["Data", _controlText],
    ["Position", [5, 14]],
    ["SliderPositions", 10],
    ["Tooltip", "Slider"],
    // ["BackgroundColor", [0, 100, 0, 255]],
    ["Size", [10,2]],
    ["SelectionFunction", "F_Slider"]
] call Zen_CreateControl;

_controlList = ["List",
        ["List", ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Gamma", "Hotel", "India"]],
        ["ListData", ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Gamma", "Hotel", "India"]],
        ["Position", [5, 0]], ["Size", [35,11.5]],
        ["FontSize", 16], ["FontColor", [233, 100, 1, 255]], ["Font", "PuristaBold"],
        ["FontColorSelected", [138, 43, 131, 255]],
        ["ForegroundColor", [100, 0, 0, 255]],
        ["BackgroundColor", [0, 100, 0, 255]],
        // ["PictureColor", [0, 100, 0, 255]],
        // ["PictureColorSelected", [100, 0, 0, 255]],
        ["Picture", ["Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa"]],
        ["ListTooltip", ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Gamma", "Hotel", "India"]],
        ["TooltipFontColor", [0, 0, 100, 255]],
        ["TooltipBackgroundColor", [0, 100, 100, 255]],
        ["TooltipBorderColor", [100, 100, 100, 255]],
        ["SelectionFunction", "F_ListClick"], ["ActivationFunction", "F_ListDoubleClick"]
    ] call Zen_CreateControl;

_controlDropList = ["DropList",
        ["List", ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Gamma", "Hotel", "India"]],
        ["ListData", ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Gamma", "Hotel", "India"]],
        ["Position", [5, 12]], ["Size", [5,2]],
        ["FontSize", 12], ["FontColor", [233, 100, 1, 255]], ["Font", "PuristaBold"],
        ["FontColorSelected", [138, 43, 131, 255]],
        ["ForegroundColor", [100, 0, 0, 255]],
        ["BackgroundColor", [0, 100, 0, 255]],
        ["Picture", ["Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa", "Test.paa"]],
        // ["ListTooltip", ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Gamma", "Hotel", "India"]],
        // ["TooltipFontColor", [0, 0, 100, 255]],
        // ["TooltipBackgroundColor", [0, 100, 100, 255]],
        // ["TooltipBorderColor", [100, 100, 100, 255]],
        ["SelectionFunction", "F_ListClick"]
        // ["ActivationFunction", "F_ListDoubleClick"]
    ] call Zen_CreateControl;

// player sideChat str ([_controlButton] call Zen_HashControlData);
0 = [_controlButton, ["FontColor", [138,43,131,255]], ["LinksTo", [_controlList, _controlDropList]]] call Zen_UpdateControl;
// player sideChat str ([_controlButton] call Zen_HashControlData);

{
    0 = [_dialogID, _x] call Zen_LinkControl;
} forEach [_controlButton, _controlButtonRefresh, _controlButtonClose, _controlText, _controlList, _controlDropList, _controlSlider];

// player sideChat str ([_controlButtonRefresh] call Zen_HashControlData);
// player sideChat str ([_controlButtonClose] call Zen_HashControlData);
// player sideChat str ([_controlText] call Zen_HashControlData);
// player sideChat str ([_controlList] call Zen_HashControlData);

player addAction ["Dialog", {0 = [_this select 3] spawn Zen_InvokeDialog;}, _dialogID];
  • Like 1

Share this post


Link to post
Share on other sites

Zen, is there a way to add the setIdentity, specifically setFace and setVoice command to the custom loadout section, in order to fully encompass the entirety of character customization in arma 3? I tried manually inserting those options and it did not work.

Share this post


Link to post
Share on other sites

Those sections aren't supported mostly because players in MP have their profile voice/face setting enforced for any unit they control. Also, I figured players won't be looking to closely at the faces of the enemy (though you can hear their voices at close range).

It's quick to make your own function to do this, e.g.:

// defined for all clients and server
F_SetFace = {
    _unit = _this select 0;
    _face = _this select 1;

    _unit setFace _face;
};

Then look at the wiki for the argument/effect locality:

https://community.bistudio.com/wiki/setFace

In this case, args are global but effect is local, so it must be run on all clients for them to see the effect:

// run on server
_args = [player, "face"];
ZEN_FMW_MP_REAll("F_SetFace", _args, call)

For this command, I'm guessing it must be synch'd in JIP as well, so let the JIP client as the server for the current face of a unit:

// defined on server
F_SetFaceJIP = {
    _faceUnit = _this select 0;
    _destinationUnit = _this select 1;

    _face = face _faceUnit;
    _args = [_faceUnit, _face];
    ZEN_FMW_MP_REClient("F_SetFace", _args, call, _destinationUnit)

    _unit setFace _face;
};

// ...

// called from JIP client
_args = [_unit, player];
ZEN_FMW_MP_REServerOnly("F_SetFaceJIP", _args, call)

and so forth for the other commands. I didn't test that, but it should be mostly correct. You'll also need to set up the JIP data to find which units to synch faces for.

Share this post


Link to post
Share on other sites

Hi Zenophon, loving your framework so far; I'm finding it to be very flexible and versatile with lots of great features for easily adding a little or a lot of randomness to a scenario.

 

Question: how would you best go about creating a mechanized group with your spawning functions? I'm having a look through the documentation and can see various options and paths I could take. Assume, though, that I want to spawn a very specific group, e.g. something akin to mech. groups you would find in the vanilla editor compositions. From what I can see, I'd have to spawn the infantry, crew and vehicle all separately, then group the infantry and crew together. Would that be the most efficient way to do it?

Share this post


Link to post
Share on other sites

Just a quick bug report, Zen_OrderInfantryPatrolBuilding didn't seem to be functioning correctly when I was using it in my mission (Units would move to a single location, stop, and not move anymore and eventually return to formation)

This is on the 10-3-15 release

 

I had a quick look at the Zen_OrderInfantryPatrolBuilding.sqf and saw on line 44 you had:

        if (isNull _x || {(alive _x)}) then {

which looked a bit odd, changing it to:

        if (isNull _x || {!(alive _x)}) then {

Appeared to fix the issue and they continue the patrol as normal :)

 

I'm enjoying the release so far just for my own mission making, looking forward to future releases. Keep up the good work Zenophon!

Share this post


Link to post
Share on other sites

Hi Zenophon, loving your framework so far; I'm finding it to be very flexible and versatile with lots of great features for easily adding a little or a lot of randomness to a scenario.

Question: how would you best go about creating a mechanized group with your spawning functions? I'm having a look through the documentation and can see various options and paths I could take. Assume, though, that I want to spawn a very specific group, e.g. something akin to mech. groups you would find in the vanilla editor compositions. From what I can see, I'd have to spawn the infantry, crew and vehicle all separately, then group the infantry and crew together. Would that be the most efficient way to do it?

Thank you, I've tried to be as thorough as possible in terms of providing critical mission features.

It depends on exactly how much control you want over what spawns. For a quick implementation, I allow the infantry to be any west soldiers and select a single vehicle:

// get the position somehow
_pos = [<...>] call Zen_FindGroundPosition;

_infantry = [_pos, west, "infantry", 4] call Zen_SpawnInfantry;
_vehicle = [_pos, ["<classname>"]] call Zen_SpawnGroundVehicle;
0 = [_infantry, _vehicle] call Zen_MoveInVehicle;
I could make this a function and pass in the position, vehicle classname, size of the infantry squad, etc; whatever arguments are required to meet the needs of the mission.

There are many paths to doing this because you can have a lot of randomness, or you can completely control the exact classname, loadout, skill, etc. of every unit that spawns. There's also the spawning of addon units to account for in the documentation.

 

Just a quick bug report, Zen_OrderInfantryPatrolBuilding didn't seem to be functioning correctly when I was using it in my mission (Units would move to a single location, stop, and not move anymore and eventually return to formation)

This is on the 10-3-15 release

I had a quick look at the Zen_OrderInfantryPatrolBuilding.sqf and saw on line 44 you had:

if (isNull _x || {(alive _x)}) then {

which looked a bit odd, changing it to:

if (isNull _x || {!(alive _x)}) then {

Appeared to fix the issue and they continue the patrol as normal :)

I'm enjoying the release so far just for my own mission making, looking forward to future releases. Keep up the good work Zenophon!

Yes, that does look like a typo. I'll change that and test for the next release. Thanks for the bug report!

Share this post


Link to post
Share on other sites
Hello , Zen

 

First I would like to congratulate you for the excellent contribution and the great work in your Framework . Thanks to you I could start customizing my own missions that could not by the Editor.

 

But, I wonder if there is to discover the city name returned randomly in this case :

 


 

_townMarkers = [["NameVillage","NameCity","NameCityCapital"]] call Zen_ConfigGetLocations;

 

 

_returnedTown = [_townMarkers] call Zen_ArrayGetRandom;

 

 

Thank you anyway!

Share this post


Link to post
Share on other sites

Update and Release #37

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

Here we have a relatively minor release, including various fixes for Zen_FindCenterPosition and a new control type for the dialog system. Zen_FindCenterPosition now operates in 3 dimensions, and an infinite loop bug is fixed.

The new 'Picture' control type will allow you to display any .paa texture file. The picture will be scaled to fit in the size of the control given, so beware of stretching and compression.

10/17/15

  • Fixed: Zen_OrderInfantryPatrolBuilding did not give further patrol order after the first was completed
  • Fixed: Zen_FindCenterPosition did not accept all combinations of position arguments
  • Fixed: Zen_FindCenterPosition entered an infinite loop when all positions had the same value for a coordinate
  • Added: Zen_CreateControl control type Picture
  • Improved: Zen_FindCenterPosition now considers the Z direction
  • Documentation: Improved for Dialog system
  • Documentation: Updated for Dialog system
  • Documentation: Updated for Zen_FindCenterPosition

Feedback

 

Hello , Zen

First I would like to congratulate you for the excellent contribution and the great work in your Framework . Thanks to you I could start customizing my own missions that could not by the Editor.

But, I wonder if there is to discover the city name returned randomly in this case :

_townMarkers = [["NameVillage","NameCity","NameCityCapital"]] call Zen_ConfigGetLocations;

_returnedTown = [_townMarkers] call Zen_ArrayGetRandom;

Thank you anyway!

Thanks, one of the framework's main goals is to enable mission-makers to do things that would have been too difficult.

So you want to know which town was selected? You could reverse the process and find the town nearest the marker, but that's not a very efficient solution. For what purpose do you want the name of the town? Is it to display the name, run specific code for each town, etc.?

I think the easiest solution is to make the name of the location the marker's text, which won't be shown for area markers. I'm just wondering if there's another solution for your situation, in case it's not that easy.

Share this post


Link to post
Share on other sites

Hello! I have been horribly underutilizing the framework's functions as I am pretty terrible at using functions and scripting in general. Even so, my crude script bashing with the tutorial f_getrandomcityAreaMarker function (calling Zen_ConfigGetLocations) and numerous uses of Zen_FindGroundPosition have really made mission building with randomized objective locations and situations a breeze. Thank you for these tools, Zenophon!

 

And so now I find myself in uncharted waters, trying to use functions from scratch, namely Zen_OrderFastRope.

 

I couldn't figure out how to spawn this function all in the init of a helicopter object (specifically, the code field of a helicopter that's specified in the ALiVE combat support transport module).

So I currently have the helicopter object spawning with this for its code (object init for every instance of ALiVE spawning the object):
 

this setVehicleVarName "air1"; this addAction ["Everyone fastrope!", "scripts\fastrope.sqf"];

Then I have this in fastrope.sqf:

_vehicle = _this select 0;
_passengers = assignedcargo _vehicle;

{
    nul=[air1, _x] spawn Zen_OrderFastRope;
    sleep .5;
} forEach _passengers;

It doesn't work. Returns undefined variable air1 whenever my player unit gets in the helicopter and uses the action Everyone fastrope!

 

Is this a problem with the setVehiclevarName on the ALiVE module? I know I'm correctly using the code field b/c it gives me the proper addAction in-game. Or have I completely goofed on the syntax for the Zen_OrderFastRope function? I've tried replacing air1 with this (also came back undefined). Also tried spawning it directly in the code/init field of the object, without an external .sqf. I suspect all my attempted changes are pointless b/c I don't know what's really wrong.

 

I originally attempted to do it without any variables, but that didn't work:

{
    nul=[air1, _x] spawn Zen_OrderFastRope;
    sleep .5;
} forEach assignedcargo air1 select 0;

Edit: I've found references in other threads to fastroping being nonfunctional in Arma 3. Would this not work anyway, even if I had the correct syntax? :D

Share this post


Link to post
Share on other sites

Hey Zenophon!

 

I wanted to point something out to you about the cleanup in the order vehicle move.

 

Specigically line 98:

if (_cleanupEnd && {(([_vehicle, _inPos] call Zen_Find2dDistance) < 25)}) then {

When I assigned cleanup to choppers or planes it didn't work but I noticed you assigned different distances to each type so I replaced 25 with this:

if (_cleanupEnd && {(([_vehicle, _inPos] call Zen_Find2dDistance) < _completionDistance)}) then {

and now it works flawlessly (so far that I can tell).

 

Anyway I didn't know if this was an oversight or on purpose but I thought I'd mention it!

 

 

 

@dakaodo try looking up in the orders functions the insertion order. That function has a fastrope option and may solve alot of your issues.

 

 

CDN_BiggDogg

Share this post


Link to post
Share on other sites

 

@dakaodo try looking up in the orders functions the insertion order. That function has a fastrope option and may solve alot of your issues.

 

It's not pretty, but I did it! It was originally a hot mess, trying to edit the helo unit's init box in the editor via the ALiVE module's code field.

 

I found you can sync a placed unit to the ALiVE combat support module, so I could directly name it w/o using setVehicleVarName. I found you can put addAction commands in the init, which allowed me to read the entire init code more easily (ugly, but avoids creating a separate .sqf that then would require variables that I don't yet fully understand how to specify). I also got lost in trying to set the fastrope function and parameters into a separate script, and kept screwing up the array of units to hoof out of the helo via fastrope.

 

So the helo named air1 now has an action available that creates an array of all passengers plus all four FFV turret unit positions. This Blackhawk has something like 12 cargo seats plus 4 doorway

air1 addAction["Fastrope deployment!",{_passengers = (assignedcargo air1) + [air1 turretUnit[3], air1 turretUnit[4], air1 turretUnit[5],air1 turretUnit[6]]; [air1,_passengers] spawn Zen_OrderFastRope}];

Next steps will be to figure out a cleaner version of the above, use addAction's parameters to restrict the access and display of the action, see if the script will interrupt the ALiVE helo during travel to a waypoint, and execute the fastrope deployment, then finish out the waypoint.

Share this post


Link to post
Share on other sites

Hello! I have been horribly underutilizing the framework's functions as I am pretty terrible at using functions and scripting in general. Even so, my crude script bashing with the tutorial f_getrandomcityAreaMarker function (calling Zen_ConfigGetLocations) and numerous uses of Zen_FindGroundPosition have really made mission building with randomized objective locations and situations a breeze. Thank you for these tools, Zenophon!

And so now I find myself in uncharted waters, trying to use functions from scratch, namely Zen_OrderFastRope.

I couldn't figure out how to spawn this function all in the init of a helicopter object (specifically, the code field of a helicopter that's specified in the ALiVE combat support transport module).

So I currently have the helicopter object spawning with this for its code (object init for every instance of ALiVE spawning the object):

this setVehicleVarName "air1"; this addAction ["Everyone fastrope!", "scripts\fastrope.sqf"];
Then I have this in fastrope.sqf:

_vehicle = _this select 0;
_passengers = assignedcargo _vehicle;

{
    nul=[air1, _x] spawn Zen_OrderFastRope;
    sleep .5;
} forEach _passengers;
It doesn't work. Returns undefined variable air1 whenever my player unit gets in the helicopter and uses the action Everyone fastrope!

Is this a problem with the setVehiclevarName on the ALiVE module? I know I'm correctly using the code field b/c it gives me the proper addAction in-game. Or have I completely goofed on the syntax for the Zen_OrderFastRope function? I've tried replacing air1 with this (also came back undefined). Also tried spawning it directly in the code/init field of the object, without an external .sqf. I suspect all my attempted changes are pointless b/c I don't know what's really wrong.

I originally attempted to do it without any variables, but that didn't work:

{
    nul=[air1, _x] spawn Zen_OrderFastRope;
    sleep .5;
} forEach assignedcargo air1 select 0;

Edit: I've found references in other threads to fastroping being nonfunctional in Arma 3. Would this not work anyway, even if I had the correct syntax? :D

For fastroping not working, that might be reference to engine-based fastroping. The fastrope code will just force each unit to exit, then just move their position in steps until they get to the ground. I doesn't always look that smooth, but it works. In the fastrope.sqf script, you have the vehicle to fastrope from in the action's arguments

 

// replace air1 with _vehicle.
0 = [_vehicle, _x] spawn Zen_OrderFastRope;
Zen_OrderInsertion with the fastrope argument is the easy way to force players/AI to fastrope. If you want to present an action, Zen_AddFastRope is fairly close to what you're doing; it's not quite as smooth because each player can fastrope independently, causing Zen_OrderFastRope to run multiple times. In general, you can always use 'air1 = this' in the editor init field to get a global variable rather than the name field.

 

Hey Zenophon!

I wanted to point something out to you about the cleanup in the order vehicle move.

Specigically line 98:

if (_cleanupEnd && {(([_vehicle, _inPos] call Zen_Find2dDistance) < 25)}) then {
When I assigned cleanup to choppers or planes it didn't work but I noticed you assigned different distances to each type so I replaced 25 with this:

if (_cleanupEnd && {(([_vehicle, _inPos] call Zen_Find2dDistance) < _completionDistance)}) then {
and now it works flawlessly (so far that I can tell).

Anyway I didn't know if this was an oversight or on purpose but I thought I'd mention it!

@dakaodo try looking up in the orders functions the insertion order. That function has a fastrope option and may solve alot of your issues.

CDN_BiggDogg

Thanks, I must've missed that when I added the variable distance change.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×