Search the Community

I find it annoying that when healing using first aid kit, the player is only 75% healed, which means you have to listen to the player moaning and groaning forever until he can be healed by a medic (by a medkit). A mission maker can solve this for you by using the eventhandler below. With this eventHandler, player is always healed 100% when healing. I'm using this in my new mission Last Tango in Tanoa 2: Razing Cane. Hopefully someone else will find this useful. I can't take credit for this, as I think I found the example somewhere (a post or wiki?), but I don't remember where. So my apologies to the original author. player addEventHandler ["HandleHeal", { _this spawn { params ["_injured","_healer"]; _damage = damage _injured; if (_injured == _healer) then { waitUntil {damage _injured != _damage}; if (damage _injured < _damage) then { _injured setDamage 0; }; }; }; }];

.

Access Points A simple to use system which allows mission makers to easily setup access points that allow players to reach places they wouldn't be able to normally reach (but should) *whew*. Why'd I make it? Because Tanoa looks pretty, but the skyscrapers don't have interiors, making players unable to access the rooftops by foot. Download: http://files.bitdungeon.org/arma/AccessPoints.Tanoa.v0.3.zip Multiplayer Compatible! Updated on 6-9-2016 Demo Video License http://www.gnu.org/licenses/gpl-3.0.en.html Setup Preliminary: Copy the "AccessPoints" directory into your mission. Copy the "execVM" statement into your mission's "Init.sqf". 1. Find yourself a nice building that you want to rig. 2. Place a trigger that you want a player to enter to access the roof. 3. Resize the trigger to better fit the doorway (optional) 4. Change the "Text" attribute of the trigger to follow the format "AccessPoint_UniquePairNameHere". This distinguishes this access point pair from the others. 5. Apply the change to the trigger text. 6. Copy the trigger (or create a new one, if you hate yourself). 7. Paste the trigger at the position you want players to be able to access. 8. Tweak the rotation and scaling of the new access point to your heart's desire. 9. Start the scenario and test it out! 10. Boom! That's it! You got it done like the badass you are. Changelog

I've been struggling for some time to create a nametag script that could: - use drawIcon3D to place the tags over players (like F3) instead of center screen (like ST) - have multiple lines of text for player roles, group names, etc - display these multiple lines (in 3D) as if they were one big sprite (psuedo-2D) ( Pictures available here ) drawIcon3D does not support structured text. It does not support text over multiple lines, or with a different justification, or any of that. You can render an icon, and you can render some text. That icon and text will always face you, and will appear the same size no matter the distance between your player and the drawIcon3D's position, but if you want to display multiple lines of text stacked upon each other you were out of luck. I was out of luck. I tried a few things. My original solution was to use the easy method (modelToWorld[0,0,0] + height for stance, +/- static Z-level spacing between tags) F3 uses, but to dynamically change the spacing between 3D icons on-screen depending on player FOV and distance to target. As you moved closer or further, the tags would space out or scrunch up in 3D accordingly. The problem? That solution only changed the Z levels of the tags, meaning that if I looked down on the tags from above (or up from below, or really any angle other than flat horizontal) the visual spacing would decrease until they appeared to overlap each other. The next attempt adjusted the spacing by first converting the world coordinates to screen coordinates (worldToScreen), adjusting those screen coordinates with a fixed Y spacing, and then converting them back into world coordinates before displaying them (screenToWorld). It worked, for the most part. Tags viewed from above would be spaced out perfectly. The problem here was twofold: first, screenToWorld gets the world position (going through models and buildings) at the screen position given, even if that world position is kilometers away. The drawIcon3D text looks the same size at any distance, of course, but this lead into a bigger problem -- If you were looking at someone and there was no "world" behind them (ie: just a sky) then screenToWorld would be unable to find a world position, and the tag would not appear. I had no idea what to do at this point and repeatedly turned to the Arma 3 Discord for help. A lot of people offered advice for which I am very grateful, but I am especially thankful towards cptnnick for helping me work through a solution to the dynamic spacing problem using orthogonal vectors and vector cross products. The solution is available in simplified form in my (unreleased, beta) nametag script, but a more expanded (and easily explained) process is this commented demonstration code graciously provided by cptnnick: comment "Setup. Not part of dynamic spacing solution."; removeMissionEventHandler ["Draw3D",missionNamespace getVariable ["drawHandler",-1]]; drawHandler = addMissionEventHandler ["Draw3D", { comment "Get the target object and player."; _target = cursorObject; _player = player; comment "Get the position of the player's camera and the middle of the target's body."; _targetPosition = _target modelToWorldVisual[0,0,1.3]; _playerPosition = positionCameraToWorld[0,0,0]; comment "Calculate the distance from target to player."; _distance = _targetPosition distance _playerPosition; comment "Get the player's current zoom level. Google 'Killzone Kid Get Zoom.'"; _fov = call wh_nt_fnc_getZoom; comment "Get the vector from target to player (GREEN LINE)."; _dir = _targetPosition vectorDiff _playerPosition; comment "NEW: vectorDir _player doesn't work when the player is using freelook."; comment "To get the vectorDir of the player's camera instead of his body, do this:"; _playerDir = _playerPosition vectorFromTo positionCameraToWorld[0,0,1]; comment "Get a vector orthogonal to the player's orientation (RED LINE)."; _cross = (_playerDir) vectorCrossProduct (vectorUp _player); comment "Get the relative "UP" direction of the target model (PURPLE LINE)."; _drawUpNormal = vectorNormalized (_cross vectorCrossProduct _dir); comment "Multiply the direction by how far we want the text spaced."; _drawUp = _drawUpNormal vectorMultiply (0.1 * _distance / _fov); comment "Flip it for down."; _drawDown = _drawUp vectorMultiply -1; _drawPosUp = _targetPosition vectorAdd _drawUp; _drawPosDown=_targetPosition vectorAdd _drawDown; comment "Render some cool drawIcon3D stuff with your new, dynamically-spaced positions."; drawLine3D [_targetPosition, _drawPosUp, [1,0,0,1]]; drawLine3D [_targetPosition, _playerPosition, [0,1,0,1]]; drawLine3D [_targetPosition, _targetPosition vectorAdd _cross, [0,0,1,1]]; drawIcon3D ["", [1,1,1,1], _drawPosUp, 0, 0, 0, "TOP", 2, 0.04, "RobotoCondensed"]; drawIcon3D ["", [1,1,1,1], _targetPosition, 0, 0, 0, "MIDDLE", 2, 0.04, "RobotoCondensed"]; drawIcon3D ["", [1,1,1,1], _drawPosDown, 0, 0, 0, "BOTTOM", 2, 0.04, "RobotoCondensed"]; }];

Hello everyone! Many servers administrators already use / used the benefits of the Headless Client in your missions. So, they probably faced several errors such as: HC that does not connect, connects and get kicked, connects and stays with an hourglass, without working (for this I have not seen any solution until the present moment, and we think we have a solution). After several tests in 2 different environments (a Windows 10 professional server - a test server - and our main server machine – windows server 2016) we discovered something that can help everyone with the problem of the hourglass HC. Administrators often use programs to manage their servers, such as SteamCMD, TADST, FLAX, and usually install an instance of Arma3Server (to use as the main server instance). Some also installs an ArmA 3 client to help with HC configuration. So far so good, but the catch is the moment that we keep the steam logged on the server (we usually leave online the steam that have the ArmA 3 client purchased). We saw that the HC worked flawless in our test server and the main server suffered with the hourglass HC. So, what we notice different on the 2 environments was (in addition to the versions of windows): * The test server always has a steam logged that does NOT have the ArmA3 client installed and, the main server, the steam logged in HAVE an ArmA3 client license. So we changed the main server environment to verify if this was the problem: * We started our main server with a Steam account that does NOT have the ArmA 3 Client, but only the Arma3 Server. Therefore, we conclude that the HC work properly when the steam account on TADST or FLAX is different that are running on server, when you start the HC instance (this prevents Steam ID conflicts and errors). We hope this information helps the ARMA 3 server administrator who use HC. Greetings from CCT – Comunidade de Combate Tático Brasil, a Brazilian Arma Community since 2009. Portuguese version: Olá a todos! Muitos já utilizam/utilizaram os benefícios do Headless Client para o servidor. Portanto, devem ter se deparado com diversos erros como: HC que não conecta, conecta e leva kick, conecta e fica com uma ampulheta (este até então, sem solução simples, pelo o que pesquisei até o momento). Depois de diversos testes em 2 ambientes diferentes (um servidor com Windows 10 profissional - este sendo um server de testes - e o servidor principal do nosso clã - windows server 2016) descobrimos algo que pode ajudar a todos com o problema da ampulheta no HC. Os administradores costumam utilizar programas para gerenciamento dos seus servers, sejam manuais ou automatizados (SteamCMD, TADST, FLAX) e costumam instalar uma instância do Arma3Server (para utilizar como a instância principal do servidor) na máquina. Como já vi em alguns post, alguns instalam o ArmA 3 client para utilizar o executável do arma3server no HC. Até aqui tudo certo, mas a pegadinha está no momento que mantemos a steam logada no servidor (costuma-se deixar a steam que possui a versão do ArmA 3 client comprada aberta no servidor). Verificamos que no servidor de testes o HC funcionava perfeitamente e no principal existia o problema. Então, analisamos o que havia de diferente nos 2 ambientes que utilizávamos (além das versões do windows): * O servidor de testes sempre está com uma steam logada que NÃO possui o ArmA3 client instalado e, no servidor principal, a steam logada POSSUI uma licença do ArmA3 client. Então mudamos o ambiente do servidor principal para verificar se o que foi constatado realmente fazia diferença: * colocamos na steam instalada no servidor principal uma conta que NÃO possui o ArmA 3 Client, mas apenas o Arma3 Server. E ao executar a missão que possui o HC, o HC funcionou perfeitamente. DESSA FORMA, CONCLUÍMOS QUE PARA O HC FUNCIONAR CORRETAMENTE, A STEAM LOGADA NA MÁQUINA DO SERVIDOR DEVE SER DIFERENTE DA CONFIGURADA NO TADST, NO FLAX OU MESMO NA STEAMCMD (MESMO QUE NAQUELA CONTA NÃO POSSUIA UMA LICENÇA DO ARMA 3), POIS ASSIM A STEAM E O BATTLEYE NÃO ENFRETARÃO CONFLITOS DE ID ENTRE O EXECUTÁVEL DO ARMA 3 SERVER E O EXECUTÁVEL DO HC. Esperamos que isso ajude os administradores de servidores de ARMA 3 e que usam o HC. Saudações da CCT a todos.