Whalenator

Most recent run I had in large multiplayer dedicated (42 people) was one and a half years ago. It worked, and it worked with headless client, using various patches I scraped up around the forums. One issue: roughly one in eight runs it gets stuck on init and floods the server .RPT with errors. Requires restart. See: https://github.com/Quailsnap/TTT1

okay this is epic

Thank you for the quick fix! I brought the problem to you, even though it was mostly on Achilles' side, just to make sure there was no vulnerability being overlooked.

Bug -- Running latest workshop @CBA_A3, @Achilles, and this mod. Crashes when attempting to use Achilles SelectPlayer "alternate" remote control (the alt+click+click one): 1. Any map, any unit. I used LDF Rifleman on Livonia. Empty mission, only a Zeus and a unlinked but automatically-assigned player in SP. 2. Alt+click+click. Crashes (after camera switch?) EDIT: I (think) the code for the module that crashes is here: https://github.com/ArmaAchilles/Achilles/blob/f11635ac67e39fb43b28ed3279fc11cd8c64abc3/%40AresModAchillesExpansion/addons/functions_f_achilles/functions/selectUnit/fn_switchUnit_start.sqf

Headless support?

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"]; }];

Necro, but this keeps showing up in search results so I'll link (another) solution here.

Had to fix an issue with freelook and some commenting stuff, but it's all ace now.

How do you use DAC with HC? Curious. I've seen solutions that literally spawn the entire script on the HC, and some that transfer AI afterwards. I have concerns about both: 1. If you're spawning the script on the HC and the HC crashes (a common occurrence in one of the larger groups I'm in), will the script crash? Will the AI be lost for the entire mission? 2. If you transfer AI locality to the HC but keep the script running on the server, can the script even control the AI anymore? Don't the units need to be local to whomever's setting waypoints? IIRC I use Vanilla DAC script version save a few minor edits made across the "Scripts" folder. I don't remember if I got my stuff from Broma, ARK, or Zriel. Something I've noticed with DAC is that during large missions after a long time (an hour into the op, for instance) the AI seem to have plenty of glitching bouts. They freeze and start shaking back and forth wildly, ignore DAC waypoints, do not respond to reinforcement calls, etc. It honestly has me wondering whether DAC is still equipped to play nicely with Arma 3's new AI FSMs.

Use whatever you like, ALiVE is more plug-n-play but less flexible. I'm only asking because after two years of using DAC for A3 it's giving me this problem for the first time. _________ EDIT: Think I finally fixed the problem. I had DAC spawn in an array of randomized positions within a minefield that was to be initialized halfway through the mission. I used turbo mode, and in DAC_Config_Creator I had the waypoint "speed limit" set to 0.01 as opposed to the usual 0.1. A null waypoint my have been spawned, someway, somehow, and gotten passed into DAC_Create_Groups. I think.

Out of the ~150 waypoints that are usually generated... the Monitor hangs at ~15, then starts generating a paltry amount of units, then throws those 2,000,000 RPT errors and DAC's script either hangs up or crashes. I ran it 38 times in local multiplayer and it happened at random but came out to roughly 1/5 times. Going to try and run some diagnostics but I honestly have no idea how to approach this given that literally forcing the script to wait until the variable is initialized does nothing.

Just a heads up -- in a mission using a script version of DAC v3.1 modified slightly to work with Headless Client (though this implementation did not use a HC), a fatal error came at seemingly random times, crashed DAC, and spammed my RPT ~2,000,000 times. pastebin.com/fhGXpDg3 There's a snippet of it. Basically the private variable _fwp in DAC_Create_Groups (and other private variables like _entry) were not being initialized before they were being used. At the beginning of DAC_Create_Groups.sqf the script makes sure to explicitly predefine these variables with both a big private[] declaration and then some assignment statements. Yet, still, somehow this code was being skipped over and resulting in a fatal error. To "fix" it (bandaid it) I threw a < waitUntil {!isNil "_fwp"}; > just below where the private variables are established. It's working so far. I have two questions: 1. Is there any other way to fix this? 2. Unrelated, but is it ever a good idea to run DAC on the Headless Client? You can't really use ACE_X HC or anything that transfers AI because then the DAC script (running on the server) can't manage them anymore. You also can't outright spawn DAC on the Headless Client because if the HC crashes it cannot recover the script. Will DAC ever truly work with HC? EDIT: Looks like it still happens. Maybe less often? I can't really tell.

Because you kiddos don't actually get on them and test. They can only do so much. For example, right now -- instead of testing different mallocs, looking through your memory profiles, and tracking leaks to help BI identify them -- you're just complaining in a forum thread.

Finally! Now I can draw Shrek's face on the map over Limni Swamp every single time we play on Altis, and I don't need mods to do it!

Got it to work with initPlayerLocal.sqf, it was a locality problem. Now if I could find a way to make these markers prettier...

I exclusively use your group markers, and would love to make them as close to F3's (http://ferstaberinde.com/f3/en//images/8/8a/Tut_img_28.png) as possible. Maybe you could give people space at the top to define custom markers for certain groupIDs? EDIT: Also I'm having some problems with JIP, a moment... EDIT2: Having problems with getting it to work in initPlayerLocal.sqf in general. It works fine in init.sqf, but if I put it separately in initPlayerLocal and initServer it doesn't work, SP MP or dedicated. Perplexing.

Hey, trying to get this thing setup for an operation. So far it works excellently, even with respawns, but I have two quick questions: 1. Is there a way to set a delay (like the pulse for units) for Group markers? 2. Is there a way to change the shape or color of markers? I'd consider adding a variable like F3 uses, and allow people to make their own templates to denote Armor/Air/etc units, and differentiate between squads with red/orange/yellow or blue/red/green, etc.

It's good to hear that you have set ban times and well-established rules (especially the increased penalty for base-revealing), but could you either have it be auto-posted to chat, or placed on the map, or in the mission info somewhere? At the very least, add it to the topic OP above, or on the WIP ofps website (if you ever need help with that btw, I'd be more than willing to assist with HTML5/PHP/MySQL development).

I saw it there yesterday, but it's not enabled right now. Probably was unstable or something, blastcore's a recent release. On an unrelated note, I would advise anyone thinking of playing on the server carefully check their attitude: admins tend to keep a hairtrigger on bans for griefers, micspammers, even rude behavior, hence all criticism should be presented politely and cautiously.

Sweet changes, but doesn't TMR already include (maybe not so effective) weapons resting? Regardless, these changes are great! Hopefully we'll see less people just dropping all their AI & initiative to fly a jet in circles lategame. Plus, removing the Town Occupation obligation will really help ease the load on the commander, so thanks for that. Can't wait for the server to get back up!

The mods work excellently, and the server's buttery smooth even compared to non-CTI missions. Sad that we only see a few CTI servers around, because BE's the way ArmA's meant to be played!

Is it possible to get the source on this? I'd love to add this to a modpack for a server.

Attachable as part of a uniform. Alternative to normal, bare-body HALO jumping. Gives increased distance, speed, maneuverability, etc. Would take ~5 sec to take off once you've landed (After pulling a parachute at low altitude, of course) I'm sure this has already been suggested, but meh. Why not. Pretty simple to hex, just a couple flat surface extensions of the same color and the uniorm. Get creative... Wingsuit machineguns? Haha.

I wouldn't worry about the level of flying difficulty in the ArmA series. It's easy stuff, just BF3 with a couple extra difficulties like lower landing angles and higher takeoff speeds. I'd worry more about not getting shot down and learning to properly use ordinance. But welcome to the ArmA family.

NEW CONGLEMERATE PLANETSIDE 2004-2010 but SOE's going to fuck up PS2, you know it they kill everything they touch