acemod / ace3 Goto Github PK

Tested on the Warrior. Shots at 1100 are inaccurate (bullet impact further than intended). I also experienced a crash of Arma3 while testing this.

For some reason i cannot understand, all the paa files from the explosives module are not loaded.

The game throws this error:

Picture \z\ace\addons\explosives\ui\explosives_menu_ca.paa not found

But the paa are there! both in the source tree and in the generated pbo.

The script_component.hpp file seems right, it is correctly included. The files are loaded with QUOTE(PATHTOF(x)) as they should, e.g.:

icon = QUOTE( PATHTOF(UI\Explosives_Menu_ca.paa) );

I couldn't find anything wrong with all this!

ACE had a small MFD for apache target and laser code selection and designation. Need to re-do this for Laser code selection. Currently, all lasers and missiles utilize laser code 1001.

disposables require inventory opening or dropping the weapon prior to disposable working. Need to clean this up a bit. etc etc

Core principle:

• Treat the gps as a device instead of an overlay

So, some ideas proposed by Jay and I:

• Hide it when the player raises the weapon: no running and gunning while looking at the gps
• Put a background behind the display as in Arma 2, like we do on map

Thar last one may be tricky.

• Place menu doesn't show
• All the paths to paa files seem wrong for some reason
• Explosives rotate without the modifier key
• The select trigger dialog is bugged
• Timed explosives doesn't work

- [ ] RMB doesn't cancel the placing

The zoom on the Vector IV seems to be far too high.
The barrels in the screenshot are 30m apart and 1 kilometre away, so there should be 30 mils between them. The FoV for the Vector IV is cited as 120 mils.

I'm trying to change agm interaction to use cba keybinds in #89, so we can remove the key handlers from AGM altogether.

The issue is that once the interaction menu opens, the cba keybinds stop working, so I cannot detect the keyUp event needed to close the menu. AGM worked around this by installing it's keyhandler functions on the dialog key events too.

Is there any way to work around this with CBA?

If not, I see two alternatives:

• Keep everything as it is until we get @NouberNou 's self interaction menu. Then scrap both AGM menus together with it's key handling routines.
• Remove agm keyhandler now and leave it's self-interaction menu crippled (only would close when clicking it's center button)

I'm leaning toward the second option so we can start cleaning common. What do you think?

Currently explosives might not entirely be AI compatible, I have never done any testing in that regard though.

From what I've seen of CSE, the modules could come in handy from the mission maker's side in setting up explosives and triggermen for those explosives. I'm not sure if there are in game commands that players can issue to AI units to place/defuse explosives but those will need to be looked at. I think defuse commands will work fine. Since internally Explosives eventually uses BIS's stuff for defusing.

Keep AGM's self interaction menu for the moment.

Hellfire L/K, etc need to be copied in and then added to the possible comanche loadouts.

Changed texture paths

Goggles was one of my first mods I made so in some places the code is fairly confusing and the use of my own macros makes the code a bit of a nightmare to work with.

There are a couple CBA events from the AGM version:

• GlassesChanged
• GlassesBroken

I currently handle "eye damage" (from explosives and from firing in dirt) by desaturation, I will probably raise an event when the eyes become damaged as well.

There are quite a few global variables used, some of them will be moved to unit variables. This will make goggles teamswitch/zeus friendly. I believe.

TODO:

• Initial port
• Make use of CBA/ACE macros where applicable
• Change to ACE events
• Remove spawns by using PFHs
  • Glasses check loop
  • Rain loop
  • Killed event handler
  • Eye damaged PP effect adjustment spawn
• Move the global variables (global to each client) to unit variables
• Fade intensity of glasses over time.

I'd potentially like to change the colour of glasses, so when they get put on, they are initially the same strength as they are currently, then over 5 minutes they slowly fade to about half the strength.

Warning: rapWarning: _missing file(s)_*****
Warning: z\ace\addons\vector\data\ace_vector.rvmat Line 14: AGM_Vector\data\agm_vector_nohq.paa
Warning: z\ace\addons\vector\data\ace_vector.rvmat Line 44: AGM_Vector\data\agm_default_as.paa
Warning: z\ace\addons\vector\data\ace_vector.rvmat Line 54: AGM_Vector\data\agm_vector_smdi.paa
rapify x32UnicodeVersion 1.75, Dll 4.90 "ace_vector.rvmat"
rapWarning: _missing file(s)_*****

• Bug:
  Some (german layout only?) ACER keyboards may repeatedly trigger onKeyDown with DIK 0. This makes it impossible to change key inputs and may break key events that have currently no set key. They acutally get executed every frame, which means never ending radio calls in ACRE or TFAR.
  Fixed by adding:
  if (_this select 1 == 0) exitWith {}
  on top of the key down eh script.
• Loading times in MP when trying to change a key
  spawn
• Key up when releasing the modifer key first doesn't trigger. It should check the modifier key on key down and then wait for a key up regardless of the current modifier state

Currently, the client preferences and the addons parameters are separate systems.

According to @jaynus on skype:

Theres 3 scenarios you have:
1. Mission maker wants certain settings by default
2. Player wants to be able to configure things
3. Server wants to be able to override #1 or #2, or both.

probably just a 1-2-3 permission system.
1 - player/client setting only (player config)
2 - per-mission setting that can override the setting of a player
3 - server can override 1 and 2.

To achieve this we need to unify both of the current systems. Some principles:

• Not all parameters would be client-setable, just those that don't modify balance nor influence third parties. Probably a very limited subset.
• Some user preferences should not be forceable by the mission nor the server.
• There should be different ways to specify parameters and preferences. Available possibilities are:
  • Config
  • Mission config
  • Modules
  • API functions
  • Client options menu
  • Server userconfig
  • User userconfig (?)
• Personally, to simplify this slightly I propose ditching the user userconfig file and use only the options menu for client preferences
• Mission config would be almost equivalent to mission modules, but just more convenient for some use cases.
• Possible priority chain, when nothing is forced:

Config < Server Userconfig < Mission Config < Modules < API functions < Client options

• Settings coul be set to forced on any of the upper levels (e.g. Server Userconfig, Mission Config or modules). That could either be for individual settings or for all settings. The forced settings would override anything defined down the chain.
• E.g: when settings are set to forced by server in server userconfig:

Config < Server Userconfig -> anything else disregarded

• E.g: when settings are set to forced by the mission in for example mission config:

Config < Server Userconfig < Mission Config -> anything else disregarded

• IMHO as much stuff as possible should be set with this ACE_parameters, allowing maximum flexibility for communities and mission makers.

This is in it's design phase, feel free to share your own ideas.

• it should be part of ace_interact_menu PBO (#63) as ace_common is getting quite bloated (We might want to rename that PBO to interact or interaction and scrap the old agm_interaction?)
• ace_interact_menu_fnc_loadingBar
  Args:
  -- Time: time it takes to complete the action.
  -- onFinish: Event (STRING) or function (CODE) thats get triggered when the action is finished.
  -- onAbort: Event (STRING) or function (CODE) thats get triggered when the action is aborted. (Either by the game or by pressing ESC)
  -- Conditions: CODE that must return true to not abort the process / loading bar.
  -- Arguments: ANY. Arguments passed to the onFinish and onAbort event.
• the loading bar aborts when:
  -- the condition returns false
  -- vehicle ACE_player changes
  -- speed ACE_player > 5 if not inside a vehicle
  -- the vehicle of the target changes, moves?
• the arguments passed to onFinish and onAbort are:
  -- _this select 0: the passed time (will be Time for onFinish)
  -- _this select 1: the arguments (Arguments)

bux578:

IRL if you're hit by a military grade flashbang you'll suffer a (in germany called: h90/3 type) sudden hearing loss, serious loss of orientation and eye damage like if you'd do arc welding without a safety mask. This usually leads to two weaks of being unable to fight (with potential hospital stay). That wouldn't be much fun in arma ... so this needs to be balanced to still be fun.

Kristian/VKing

Flashbangs should knock you out for at least long enough for someone to clear the room you're in
it really needs to be limited to Line of Sight, though
if there's someway to make it work, it should have a greater effect indoors, even if you don't see it, than outdoors

We are using multiple styles of headers in our functions.

CSE:

/**
* FILENAME
* @Descr: 
* @Author
*
* @Arguments: []
* @Return
* @PublicAPI: false
*/

AGM:

/*
Name: FUNCTION_NAME
Author: AUTHOR
Description:
DESCR
Parameters:
0: ...
Returns:
VALUE
Example:

*/

I have noticed a few other variants of this in multiple functions, some with * at the start of every line, some without.

I think we should start doing headers constantly in our function files. Any suggestions for which style we will follow?

Apparently BI fixed the addActionEventHandler for the "MenuBack" action, so we need to change explosives placement cancelling to something else than pressing RMB.

Luckily, the hack stil works for "DefaultAction", so jamming and weapon safe are fine.

The returned ID of CBA_fnc_addPerFrameHandler is not actually unique. IDs get reused after removing a handler via CBA_fnc_removePerFrameHandler.
This makes it impossible to try to remove a handler in multiple places, because the second execution of removePerFrameHandler might remove a totally different handler.

Can be tested by using:

A = [{0}, 0, [0]] call cba_fnc_addPerFrameHandler;
[A] call cba_fnc_removePerFrameHandler;

-> A doesn't increase.

The IMO better behavior of AGM's eventhandlers:

A = [player, "My",{}] call ace_common_fnc_addCustomEventhandler;
[player, "My", A] call ace_common_fnc_removeCustomEventHandler;

-> A does increase. The eventhandler ID is unique.

The eventhandlers from BI have a similar issue, where, if you remove the last handler of a type, the ID's reset. The better behavior can be observed by executing:
A = player addEventHandler ["Fired",{}];
once, and then executing:

A = player addEventHandler ["Fired",{}];
player removeEventHandler ["Fired",A];

-> A is unique and increases.

for appropriate javelin flight path and UI

Nou:

• if you are referencing something taking place across game time then time is best to use
• if you are referencing something taking place across processing time, diag_tickTime is best to use

diag_tickTime is in millisecs, not affected by time acceleration and increases throughout the frame. Time acceleration can be obtained with accTime.

• nametags
• others

@NouberNou, according to commy the ACE event handlers ID are reused, so they are not really unique.

Could they be wrapped like you did for CBA PFH, so they produce a unique ID?

This would make removing them much more safe. Also more consistent.

The first two come from agm, the last from cse. Unify the style on the three, or, if possible, use them as front end to a single generic function.

In the event that we have a situation where non-open source licensed models are required for core systems we need to have a solution for still keeping the raw, unbinarized models and content in source control.

My solution is a separate repository that we check out, it's addon prefix path would be z\ace_m\addons and any modules in z\ace\addons that require a non-open source model would create module in there but with a _m suffix to the module name. For example z\ace\addons\wep_dragon in the main ACE repo would be z\ace_m\addons\wep_dragon_m in the ACE model repo and it would contain all the models, model.cfg files, and textures for the Dragon missile. Build scripts would build both repos and combine the PBOs into one release.

That I feel is the easiest solution.

• interaction
• ...

["test1", {systemChat format ["test1 %1", _this];}] call ace_common_fnc_addEventHandler;
player addAction ["test 1 player", {["test1", player, ["player", player]] call ace_common_fnc_targetEvent;}];
player addAction ["test 1 targ", {["test1", cursorTarget, ["target", cursorTarget]] call ace_common_fnc_targetEvent;}];

In SP Editor:
player works
cursorTarget doesn't
Works fine in MP

This should monitor the inventory via PFH and trigger local events for inventory changes.

The earplugs 3d model expects the texture to be on agm_hearing\ui\earplug_co.paa

Run cba_fnc_registerKeybind on the XEH_postInit of each module:

AGM:

class ACE_Default_Keys {
    class clearJam {
        displayName = "$STR_ACE_Overheating_UnjamWeapon";
        condition = QUOTE( [_player] call EFUNC(common,canUseWeapon) && {currentWeapon _player in (_player getVariable [ARR_2(QUOTE(QGVAR(jammedWeapons)), [])])} );
        statement = QUOTE( [ARR_3(_player, currentMuzzle _player, false)] call FUNC(clearJam); );
        key = 19;
        shift = 1;
        control = 0;
        alt = 0;
    };
};

ACE:

// XEH_postInit.sqf
["ACE3",
   localize "STR_ACE_Overheating_UnjamWeapon",
   { [-1] call FUNC(fnc_clearJamKeyPress) },
   [19, [true, false, false]],
   false,
  "keydown"] call cba_fnc_registerKeybind;

// fnc_clearJamKeyPress.sqf
if !([ACE_player] call EFUNC(common,canUseWeapon)) exithWith {};
if !(currentWeapon _player in (ACE_player getVariable [QGVAR(jammedWeapons), []]) exitWith {};

[ACE_player, currentMuzzle ACE_player, false] call FUNC(clearJam);

Function: CBA_fnc_registerKeybind

Description:
Adds or updates the keybind handler for a specified mod action, and associates
a function with that keybind being pressed.

Parameters:
_modName Name of the registering mod [String]
_actionName Name of the action to register [String]
_code Code to execute upon event [Code]
_defaultKeybind Default keybind [DIK code, [shift?, ctrl?, alt?]] [Array]

Optional:
_overwrite Overwrite existing keybind data? [Bool](Default: False)
_keypressType "keydown" (Default) = keyDown, "keyup" = keyUp [String]

Returns:
Returns the current keybind for the action [Array]

It would seem that the IEDs were left out of the explosives handling (it's entirely my fault).

Perhaps some cellphone handling would be in order for IEDs?
I have done it before https://www.youtube.com/watch?v=-edcF0fQc-U

I'm used to doing a lot of run once spawned code:

[] spawn {
sleep 1;
do something
};

converting this to CBA's perFrameHandler would be easier if we could just do something like

[_func, 1, [], true] call CBA_fnc_addPerFrameHandler

where the 4th param controls delaying first execution

private["_handle", "_data", "_delayFirstRun", "_timeToRunFirst"];
PARAMS_2(_func,_delay);
DEFAULT_PARAM(2,_params,[]);
DEFAULT_PARAM(3,_delayFirstRun,false);

_handle = -1;
if (!isNil "_func") then {
    _handle = GVAR(nextPFHid);
    if (_handle == -1) then {
        _handle = count GVAR(perFrameHandlerArray);
    } else {
        _test = GVAR(perFrameHandlerArray) select _handle;
        if (!isNil "_test") then {
            _handle = (count GVAR(perFrameHandlerArray));
        };
    };
    _timeToRunFirst = if (_delayFirstRun) then {_delay + diag_tickTime} else {0};
    _data = [_func, _delay, _timeToRunFirst, diag_tickTime, _params, _handle];
    GVAR(perFrameHandlerArray) set [_handle, _data];
};
_handle

Make stuff follow:
https://github.com/KoffeinFlummi/ACE3/wiki/Modularity-and-PBO-Structure

partially depends on #63

My personal checklist:

• ai
• aircraft
• attach
• backblast
• ballistics
• common
• difficulties
• disposable
• fcs
• flashsuppressors
• frag
• interaction
• inventory
• laserpointer
• lockbackpacks
• magazinerepack
• magazines
• main
• map
• markers
• missileguidance
• movement
• nametags
• nightvision
• noradio
• optionsmenu
• overheating
• protection
• ragdolls
• realisticnames
• recoil
• reload
• respawn
• resting
• safemode
• scopes
• smallarms
• switchunits
• thermals
• vector
• vehicles
• weaponselect
• weather
• wep_dragon
• wep_javelin

@NouberNou, check this code:

https://github.com/KoffeinFlummi/ACE3/pull/24/files#diff-0276fcc579ec0a4e0fac5dbb7357afeaR18

In that code, when a flashbang explodes the "ace_grenades_flashbangExplosionEvent" event is raised once for every target, pasing the target unit in each instance. The hope is that the EH is called once for every affected unit with the correct locality.

Is this usage correct? Will the event handler be executed multiple times on the affected machines?

Of course this can be rewritten to raise the event only once, but I wonder if this kind of usage is acceptable.

just a reminder KoffeinFlummi/AGM#2024

On the FV510 Warrior (I_APC_tracked_03_cannon_F):

When trying to engange the NV mode on the gunner seat:
Error: 'gunBeg/' is not a class ('visionMode' accessed)

When trying to engange the NV mode on the commander seat:
Error: 'memoryPointGunnerOutOptics/' is not a class ('visionMode' accessed)

Other vehicles, like the Namer, work fine.

This happens with @PabstMirror port of NightVision, as well as with the modified version based on ACE events that I'm about to commit. May have been a problem in AGM even, although I haven't tested that yet.

Porting over the CSE medical / CMS module to ACE.

TODO:

• Initial port.
• Implement a basic, medium and advanced level.
• Enabling the system by default (on basic level).
• Rewrite of actions (examine, treatment, carry, etc) handling.
• Rewrite of treatment options additions.
• Port over the support modules for medical actions (such as assign medic role, medical vehicle, medical facility, basic revive, etc).
• Change texture paths for models.
• Add AGM's method of preventing handleDamage to fire multiple times for the same hit.
• Merge CMS and AGM's effect handling.
• Improve carry and drag functionality.

Edit: leaving the new menu out for a future update.

PFH don't work on the briefing screen because they depend on the onDraw event of a CfgTitle shown with cutRsc, and cutRsc doesn't work on the briefing screen.

Having PFH working there would be usefull, at least to keep the coding style consistent; if not we need a bunch of spawns for certain things.

We checked the latest cba code and added a hack in ace_common that solves this by ticking the PFH with an onEachFrame event during the briefing:

97ee63a

However, something like this could be landed directly on CBA.

This is in local mp (2 exes on same comp)
Problem is in map, but here a test case in init.sqf:

["event1", {systemChat format ["event1 %1", _this]}] call ACE_common_fnc_addEventHandler;
player addAction ["Event 1 global", {["event1", [player, "global"]] call ACE_common_fnc_globalEvent;}];
player addAction ["Event 1 local", {["event1", [player, "local"]] call ace_common_fnc_localEvent ;}];
player addAction ["Event 1 target", {["event1", cursorTarget, [player, "target"]] call ace_common_fnc_targetEvent ;}];

Global/Target never fire on remote. Added this test:

"ACEg" addPublicVariableEventHandler {systemChat "New ACEg1";};
[] spawn {
    "ACEg" addPublicVariableEventHandler {systemChat "New ACEg2";};
};

Only "ACEg2" shows on remote

biki has something about not being able to add this durring preInit
https://community.bistudio.com/wiki/addPublicVariableEventHandler

but we add them in XEH_postInit, so not sure how to fix.

Log states
missing \ca\data\penetration\metalplate.rvmat

Integration from the new medical module with other modules such as backblast.

This topic is for collecting all subjects that needs to be discussed for the dev meeting on Saturday 31 Jan '15 18:00 UTC.

Subjects:

• Responsibilities:
  • Merging/Accepting PRs
  • Project management
• Roadmap
• Duplicate functionality (ACE/AGM/CSE)

If there is anything else that needs to be discussed, please post it in a reply to this issue.

Instead of AGM system:

// tapper machine
[[arguments], QUOTE(FUNC(tapMyShoulder)), _target] call EFUNC(common,execRemoteFnc);

// target machine XEH_preInit.sqf
PREP(tapMyShoulder);

Use Nou's new ACE Event System:

ace_common_fnc_addEventHandler
ace_common_fnc_globalEvent
ace_common_fnc_targetEvent
ace_common_fnc_serverEvent

Pattern:

// tapper machine
["tapShoulder", [_target], [otherArguments]] call EFUNC(common,targetEvent);

// target machine XEH_preInit.sqf
PREP(onTapShoulder);
["tapShoulder", FUNC(onTapShoulder) ] call EFUNC(common,addEventHandler);