Jump to content

Whalenator

Member
  • Content Count

    44
  • Joined

  • Last visited

  • Medals

Community Reputation

15 Good

About Whalenator

  • Rank
    Lance Corporal

Contact Methods

  • Website URL
    https://github.com/Quailsnap?tab=repositories
  • Biography
    Arma modder, player, missionmaker since late Arma 2 days.
  • Twitter
    https://twitter.com/Quailsnap
  • Youtube
    https://www.youtube.com/user/DrWhalenator
  • Steam url id
    https://steamcommunity.com/id/dontclickme

Profile Information

  • Gender
    Male
  • Location
    Illinois, USA
  • Interests
    Code, play, create.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. Whalenator

    Arma Zeus Cache

    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.
  3. Whalenator

    Arma Zeus Cache

    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
  4. Whalenator

    Multi-line text with DrawIcon3D

    Necro, but this keeps showing up in search results so I'll link (another) solution here.
  5. Had to fix an issue with freelook and some commenting stuff, but it's all ace now.
  6. 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"]; }];
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Whalenator

    Line Drawing

    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!
  13. Got it to work with initPlayerLocal.sqf, it was a locality problem. Now if I could find a way to make these markers prettier...
×