genesis92x

For me, a new generation of coders will need to continue work for ArmA Reforger. I love a lot of the improvements for the Enfusion engine, however there are a lot of concerns that I have with Reforger. It's hard for me to want to spend many hours coding for a game that I will not be playing. I was contemplating messing with Enfusion but just decided to move over to Unity and make my own projects for fun until ArmA 4 comes out.

I haven't logged onto this website in years, and I logged in to let you know that I am amazed with that UI. Absolutely beautiful. The amount of work and love that went into that is insane.

I remember that animation...now that I am thinking about it...I thought A3 had it as well. And yes, the AI will climb rock faces. I'm not sure to what extent they will, but I have seen them mount boulders to engage others. 1) Go into the !Workshop folder and find Vcom, pull the userconfig folder from there into your root A3 folder. Or you can use CBA to edit almost every setting. 2) They will sit around until they are given new orders. Unless the AI are in combat, Vcom should not be assigning new waypoints. 4) You will need to adjust the settings appropriately. The default is only a 10% chance to use every few seconds or so. Also, everyone on the server needs to be running enhanced movement. The original enhanced movement. Any forked versions WILL NOT WORK. this enableAI "RADIOPROTOCOL"; should fix it. I believe I disabled it so the AI would respond faster to orders.

I'm not sure if that's a good idea or not. In general, it's not a good idea to mix AI mods. You would have to give it a test. I am unaware of what GAIA actually does to make a good guess on that.

Believe its on the steam page - just not in the changelog There is an experimental driving option. It is what it says it is. Experimental. It attempts to prevent AI from running over friendlies, it also helps them navigate around obstacles that AI would normally run into without second thought (Think of sandbags in the middle of a road). It is however, not perfect. I can't remember the last time the AI moved in fast speed....so no. That is an option you can toggle now, and it only impacts them in combat. Vcom really doesn't do much until the AI get into combat. Combat somersault animations? Whatttt are you talking about. That sounds silly and fun.

Edit to your hearts content This is a late response...but here goes anyway. You cannot toggle Vcm_disable unfortunately. Although that would be a good idea. What you CAN do is set vcm_disable to false, and then run this code "_group spawn VCM_fnc_SQUADBEH;" , which will execute Vcom on the group again. The reason for this is that the scheduler I use just skips squads that have been disabled, I did this intentionally to save on precious FPS in an infinite loop that constantly checks for AI groups - although there are simple work-arounds as above. As for your 2nd question, vcom now supports classname based skill settings. However, this can be quite tedious....but possible.

I am not the best at this - but I am assuming you want the code that will open the door? Or do you just want the door name? Or the doorsource name, in order to make it open/close? Here is an example of how I find doors in one of my scripts. I am sure there are better ways, you will have to adjust the scripts below to your needs. This code below runs in a loop - constantly checking for doors in buildings, and then executing code once a door is found. private _SelectionNames = (selectionNames _building); { if (["door",_x] call BIS_fnc_inString) then { private _doorPos = _building selectionPosition _x; private _WorldPos = (_building modelToWorld _doorPos); if (player distance2d _WorldPos < 3) then { private _Door = [_x, "dDoor_0123456789"] call BIS_fnc_filterString; if !(missionNamespace getVariable [((str _Building)+_Door),false]) then { private _HandleObj = "#lightpoint" createVehicleLocal _WorldPos; _HandleObj setpos _WorldPos; [_Building,_Door,_x,"Door",_HandleObj] spawn INT_fnc_DoorDraw; }; }; }; } foreach _SelectionNames; Code snippet from DoorDraw function: This part adds the door, among other things, to an array and adds a displayhandler that will allow the player to open/close a door by using their scroll wheel. I am assuming the way to get the door sourcename is what you are after? Look at the variables _Doorsource and _DoorNoSource. private _DoorArray = [_Building,_Door,_HandleObj]; INT_SelectedDoors pushback _DoorArray; _INT_SlowOpen = (findDisplay 46) displayAddEventHandler ["MouseZchanged", { params ["_displayorcontrol", "_scroll"]; { _x params ["_Building","_Door","_HandleObj"]; if ([player, _HandleObj, 0] call BIS_fnc_isInFrontOf) then { private _DoorSource = format ["%1_sound_source", _Door]; private _DoorNoSource = format ["%1_nosound_source", _Door]; private _p = _Building animationSourcePhase _DoorSource; if (_scroll > 0) then {_p = _p + 0.4} else {_p = _p - 0.4}; if (_p > 1) then {_p = 1}; if (_p < 0) then {_p = 0}; _Building animateSource [_DoorSource, _p]; _Building animateSource [_DoorNoSource, _p]; }; } foreach INT_SelectedDoors; } ];

This is a month too late, but I ran into a similar issue yesterday and wanted to post a potential solution. I started by looking at how the BIS_fnc_UnitPlay function makes vehicles follow a set of points *smooth-ish=ly*. That function uses setvelocitytransformation. object setVelocityTransformation [fromPosASL, toPosASL, fromVelocity, toVelocity, fromVectorDir, toVectorDir, fromVectorUp, toVectorUp, interval] With some careful planning, you can create an array of positions and iterate through it to get the AI to "drive" the boat down the water. If you use this method, you would have to add checks for things like combat, a dead driver, dead vehicle, or a halted boat that interrupt the loop. Otherwise you will have a ghost boat driving around.... Which sounds fairly cool anyway.... The only other solution I could think of...would to be constantly nudging the boat forward and away from the shore... using abs (getTerrainHeightASL (getposASL _boat)) you can constantly be checking the depth of the water - and if it gets too shallow, have a function setvelocitytransformation away from the edge of the water. This method would most likely create a drunken driver effect...as the AI LOVE to just drive boats into the shore.

Another interesting behavior to add on with this, if you use displayRemoveAllEventHandlers it does clear the index's of the EHs. If you individually remove an eventhandler it does not remove the index from display handler list. However, if you remove all the indices manually, it does eventually return the index count back to 0 when adding a new event handler. This behavior exists when using local variables for eventhandlers as well. My guess is that this is not really a big issue...the only potential concern would be that during a long running mission, a players total index number for displayhandlers could potentially reach the thousands or higher. Although I still do not see how this would really cause any FPS or script lag issues - as ArmA seems to handle large numbers decently well...however that is only if the displayeventhandler index storage is not actually a giant array. I am not sure how Bohemia stores those into memory.

It should be as simple as putting it into the right missions folder and loading it :/ are you getting an error?

Great script 🙂 Keep up the hard work

Yeah, you got it 🙂

I know this is several days later - did you notice any difference between using agents as drivers instead of standard AI? If I recall in my previous testing - agents seemed to perform better in situations with setdriveonpath

Make a request on the GitHub - once I get time I can get around to it. I typically don't have issues with them getting back into their aware behavior

The skill settings are not in the CBA settings currently - they will be added once I get back to Vcom for the next update.