emrak

Anyone? Is this not the right place to post things-that-could-be-bugs?

While I love the new Spectator Mode in almost every respect, there is one thing that is keeping me from using it (instead of our current custom scripted solution): moving around as a spectator becomes incredibly slow after a minute or so. Even holding LShift + Q, I seem to elevate at a geriatric rate. I get the same results with moving forward and backwards. Obviously I'm in 3rd Person View when trying this. Is there a setting somewhere that I'm unaware of or is this a bug? Additionally, the F1 text box states that I can use LMB to select a unit (and thus display details) and then use LMB again to unfocus (and presumably not display unit details). However, the unit details box never goes away. Thanks

Worked like a charm. Thanks Tom!

Good day. When I use the GameUpdater utility found in Arma 3 Tools, I consistently get the following behavior: 1) I open GameUpdater, my account is logged in and works fine. 2) I set the installation directory to a "DevBranch" directory OR my default Arma 3 install directory (doesn't matter, I've tried both). 3a) If I click "Options" then the below error appears. 3b) Alternatively, if I click "Update" then the GameUpdater screen simply closes and nothing happens. No errors and it's not running in the background at all. Logs No logs are generated in the "\Arma 3 Tools\GameUpdater\logs" directory. A log is generated in the "\Arma 3 Tools\Logs" directory and the error is shown below. 2016-04-22 14:29:14,301 [INFO]: ===================================================================== 2016-04-22 14:29:14,317 [INFO]: == Begin of trace == 2016-04-22 14:29:14,317 [INFO]: Available hard drive(s): 2016-04-22 14:29:14,317 [INFO]: Fixed C:\ - isReady=YES - totalFreeSpace= 70GB 2016-04-22 14:29:14,317 [INFO]: Fixed D:\ - isReady=YES - totalFreeSpace= 182GB 2016-04-22 14:29:14,317 [INFO]: Fixed E:\ - isReady=YES - totalFreeSpace= 111GB 2016-04-22 14:29:14,317 [INFO]: Fixed F:\ - isReady=YES - totalFreeSpace= 119GB 2016-04-22 14:29:14,317 [INFO]: Fixed P:\ - isReady=YES - totalFreeSpace= 182GB 2016-04-22 14:29:14,332 [INFO]: SteamCMD version: 2.91.16.71 2016-04-22 14:29:14,332 [INFO]: development version is:1.58.135.656 2016-04-22 14:29:14,348 [INFO]: Install directory appears to be ok 2016-04-22 14:29:14,348 [INFO]: development/kvsignatures/InstallScript 2016-04-22 14:29:14,348 [INFO]: 6ea9384716248cba314fedd5ade98c62fa58da5599ca9b192dca2ff52941ca6dd3101cd1035001d746774a8ed1b457303090a4342c7ab106d582a56df0fb3462d6be5eacc5a4c32283bdddbb7f762da884dfd824fa133a55b45bf6a54b0357ab5693e21f7f5b481789fdc15eb53d46254a8f01f50c023bba68933b9ce59d07fb 2016-04-22 14:29:14,348 [INFO]: App_info source: D:\Program Files (x86)\SteamLibrary\steamapps\common\Arma 3 Tools\GameUpdater\107410.data 2016-04-22 14:29:18,020 [FATAL]: == UnhandledException == 2016-04-22 14:29:18,020 [FATAL]: Sender: gameupdater.My.MyApplication 2016-04-22 14:29:18,020 [FATAL]: Exception message: Conversion from string "" to type 'Integer' is not valid. 2016-04-22 14:29:18,020 [FATAL]: HResult: -2147467262 2016-04-22 14:29:18,020 [FATAL]: Message: Input string was not in a correct format. 2016-04-22 14:29:18,020 [FATAL]: Source: Microsoft.VisualBasic 2016-04-22 14:29:18,036 [FATAL]: StackTrace: at Microsoft.VisualBasic.CompilerServices.Conversions.ParseDouble(String Value, NumberFormatInfo NumberFormat) at Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger(String Value) 2016-04-22 14:29:18,036 [FATAL]: TargetSite: ParseDouble 2016-04-22 14:29:18,036 [FATAL]: MethodHandle: 1467315180 2016-04-22 14:29:18,036 [FATAL]: Ms HelpLink: System Info I'm running Windows 10 Home, if it matters. Things I've tried Rebooting. Verifying Arma 3 Tools cache integrity in Steam. Switching from the stable Tools branch to the development branch. Mounting the P/WorkDrive and running GameUpdater. Reading the Tools and GameUpdater manuals. Running naked through the streets and shrieking at the moon. Please advise. Thank you.

But that will overwrite the current Steam build, which I don't wish to do. There is typically a different code word to use for SteamCMD, so instead of 107410 -beta development It might be something like 107410 -beta TitleOfVisualUpgrade Or whatever. Does anyone know what the 1.6 beta code word is? Thanks

I am only getting the current (live) 1.58 branch when I run my old dev branch SteamCMD script. Did something change? Where can I find the 1.6 visual upgrade branch? Thanks. My current script is below. @ECHO OFF SET STEAMUN= <myusername> SET STEAMPW= <mypassword> SET ARMASVRPATH=D:\GameDev\Arma\ArmaDevBranch SET ARMABRANCH=107410 -beta development "D:\Program Files (x86)\SteamLibrary\steamapps\common\Arma 3 Tools\GameUpdater\steamcmd.exe" +login %STEAMUN% %STEAMPW% +force_install_dir "%ARMASVRPATH%" +app_update "%ARMABRANCH%" validate +quit pause

The moon phases in A3 are out of alignment with the real world as per trouble tickets. It would also seem that the "moon" object in the in-game night sky is actually irrelevant as the "moon" lighting occurs on the ground functionally (i.e., the "moon" is not a thing that shines down, it's just an indicator for the engine to generate "moon light" on the surface) and this non-moon "moon light" generated on the surface may be out of sync with the in-game moon phases. I know that overcast weather can diminish the effects of light. I know that there's a way to change the "aperture" setting to manipulate brightness as well. Due to my confusion over the above issues and my desire to save time, can someone who's been down this path please give me the in-game date/time/weather/aperture setting to create the darkest night possible? Thank you! p.s.--yes, I know people can brighten their environment via brightness/gamma.

OK, I think I understand what you're saying now. Your description of the problem is confusing because you are using the words "respawn" and "spawn" incorrectly. You actually have no problem with respawn at all, I think. Here's what's actually happening: There are two sides with two respawn markers (east and west). When they die, they respawn at the markers as they should. All is well. However, after a player has respawned at their appropriate marker, you have created a button dialog that the player may click to instantly move ("teleport") to location X. This "location X" is determined by whether or not another player (commander in this case) has activated an addAction command. If this is accurate, then here's some information. When "BASE" is set in description.ext and a player dies, the game will look for any local and global markers that begins with "respawn." Understand that respawn markers have a hierarchy that starts with the player and slowly goes up. The game will: 1) Look for markers named "respawn_Player" 2) Look for markers named "respawn_Player_GroupLeader" 3) Look for markers named "respawn_Player_Side" 4) Look for any markers that start with "respawn" 5) Just spawn the player where they died. So my suggestion to you would be to: --Copy the mission folder so you have a backup --Delete everything related to the "addAction" command (all the files, ForwardHQKilled.sqf, etc.) and your button. From here, you can: 1) Create an addAction without any confusing arrays checking for numbers and so forth, such that all it does is call a script that creates a building, a marker, a trigger, and finally removes the addaction from the commander. The marker will be named "respawn_name_of_dude_who_put_the_marker_down". The building has no code associated with it. The trigger will simply be checking if the building is alive (or you can have it check the "damage" level). When the building is not alive, the trigger will run code that deletes the marker, adds the addAction back to the commander, and finally deletes itself (the trigger). 2) Or, you can do #1 but use the eventhandler (possibly mpeventhandler? not sure without testing) for the building instead of a trigger. 3) Or, you can do #1, but MOVE the original "respawn_west/east" marker to the current location using setMarkerPos. And on building destruction you would then setMarkerPos back to the original location. In this case there would never be another marker at all. In all the above, what would now happen is a player would die and then respawn at the HQ directly, with no need to teleport. If you are just looking for a script to teleport to a dynamically set location, then please google. There are tons of examples.

So...you're saying you want two triggers then? One that kicks off instantly when a player brings the briefcase in and then another trigger that has a timeout set in case the briefcase gets removed in time? ;) Keep it simple man. EDIT: if you want there to be a "toggle" with the two triggers then you're already on the right path. Simply create a toggle variable. One trigger sets it to true and the other sets it to false as part of their onActivation and they're both checking for the appropriate condition. Both triggers will need to be repeatable in that case.

There's a lot going on here. First thing though, do you really want that "sleep 1200" (that's 20 minutes) in your killed Event Handler? What is its purpose? Second, how are you setting respawn in your description.ext file? If it's not "BASE" then your units will never be able to respawn on markers (I'm assuming it is though). Moving right along... So you want to create an addAction on some player. This would allow player to create a building and then (through some scripting) also put a respawn marker at the building's location. Is this accurate? If so... 1) addAction is a local command. I.E., the script will run once on the specific player's machine. 2) createVehicle is a global command. I.E., it will run once on all machine's (including the server) each time it is used. 3) "killed" is a local event handler. I.E., it will run where the "killed object" is local. I'm not entirely sure what will happen when placed on a globally created vehicle. 4) createMarkerLocal/deleteMarkerLocal are local commands. That was all just an FYI so you understand (as barbolani pointed out) the locality involved here. Lastly, assuming you have "BASE" set in your description.ext, I still fail to see where you are actually placing a respawn marker. Your code is this: _mrk = createMarkerLocal ["HQ_marker", [Forward_HQ select 4, Forward_HQ select 5]]; Which does not create a respawn marker. All such markers must begin with the word "respawn." See https://community.bistudio.com/wiki/Arma_3_Respawnfor more info. I suspect you simply have the starting respawn location around the same spot where you are testing, thus (since there are no respawn markers) the players simply respawn where they started the mission at.

The easiest solution that comes to mind is to simply set the "timeout" of the trigger that is checking for the briefcase. This way you do not need a timer script at all. See these links: https://community.bistudio.com/wiki/2D_Editor:_Triggers#Countdown.2FTimeout_Counters https://community.bistudio.com/wiki/setTriggerTimeout

A trigger is not necessary for this task. Have you considered using onPlayerRespawn.sqf script? Or for a simpler route, try placing code in each player's init box (in the editor) as shown in this link: http://www.armaholic.com/forums.php?m=posts&q=20889I have not tested this BTW.

BIKI says createVehicleLocal is a local command and generates a local object with no data transfers over the network in a multiplayer game. There is no "deleteVehicleLocal." In fact, there are no other *VehicleLocal commands at all (I.E., no "setVehiclePositionLocal"). BIKI says deleteVehicle and setVehiclePosition are global commands which delete and move objects. So--assuming this code runs on a player's computer--if I create an object via createVehicleLocal, then move the object via setVehiclePosition, then delete the object via deleteVehicle, am I ever leaving the player's computer and transferring info over the network to the server? Bottom line: if I invoke anything using a local command and then modify/remove it with a global command, is there ever any network traffic?

This sounds like an avenue to pursue! Do you have any brief examples you could describe? Thanks

I'm really not concerned about micro-optimization, I just come from a standard programmatic background wherein testing occurs early and often. In a normal programmatic job, it's so easy to test and generate metrics for a given application. I feel like I'm blind without knowing how long it will take a mission to load and/or what it's overhead will be. I hope I'm making sense. :) Simply posting a mission without having any performance metrics and waiting for feedback from players seems like a 1990s/turn-of-the-century development approach (I know, I was coding then lol). EDIT: And I will definitely check out diag_fps. Thanks for bringing that up!