LymeM   2 Posted August 26, 2020 10 hours ago, killzone_kid said: For starters Linux server is built with every change in code together with win version. Also if releasing 64-bit Linux server is not showing love towards Linux server, then I dont know what is. Hence, are you a troll?  On 7/20/2020 at 1:25 AM, Dedmen said: Do we even have a linux dev-branch? I thought we didn't 🤔 Currently x64 is in perf/prof branch only experimental testing, so far it looks like we'll release it with next update though, if you can confirm me that we have a linux server dev branch at all I'll check that we get x64 added to that.  Edit: Okey I asked, we don't have dev-branch for Arma 3 Server at all, and as Linux is server only we don't have any Linux dev branch (Windows client dev branch also includes windows server binaries). If you have some very special and important need, you can try catching me on a day with lots of free time (basically doesn't exist ) and i can give you a build (I personally run dev-branch x64 linux for my unit anyway, but would need to make a seperate build for public which takes about 30 minutes and as I said I usually don't have the free time soooooo)  Please read the bolded text. Are you a troll?  Share this post Link to post Share on other sites
SuicideKing   233 Posted September 2, 2020 So there's a crash associated with how Arma handles large textures that's become a bit of a persistent problem when trying to use Global Mobilization assets. The game seems to be unable to handle memory efficiently after a point, and then the system runs out of it. Happens on both stable and perf/profiling branch, although with the performance binary it didn't crash but still went down to 1fps for a prolonged period of time (i.e. game freezes or responds very slowly). It's reproducible. I have made a ticket here: https://feedback.bistudio.com/T153532  I've logged system data while testing and uploaded a bunch of CTD reports (as generated by the Arma launcher) that occurred over the last few months. Back in April it was DX11 out of memory errors, then i increased page file significantly and that settled down. However the issue cropped up again with a general memory access issue. Increasing page file is a workaround but it's not a fix, it only delays the slowdown and eventual crash.  I've seen the issue a lot on the global mobilization discord, so it's definitely a widespread problem and a bit of a headache. the repro steps may seem excessive but it has happened during normal mission editing too. I will post the ticket in the GM discord so that other people might provide additional inputs as well. 4 2 Share this post Link to post Share on other sites
2nd ranger   282 Posted September 3, 2020 On 9/2/2020 at 2:44 PM, SuicideKing said: So there's a crash associated with how Arma handles large textures that's become a bit of a persistent problem when trying to use Global Mobilization assets.  Glad it's not just me - I often get slowdowns and crashes when using GM assets, and Livonia. I'm afraid to use GM vehicles because they cause significant frame drops just by looking at them the wrong way. 1 Share this post Link to post Share on other sites
AveryTheKitty   2626 Posted September 13, 2020 https://feedback.bistudio.com/T153805  Respawn bags can't be moved around - you will always spawn at the first place you deployed it. Share this post Link to post Share on other sites
lexx   1363 Posted September 13, 2020 I have the class hgun_P07_blk_F visible in Virtual Arsenal, which - as the name suggests - is a black variant of the P07 pistol. However, it shows the khaki inventory icon and "community addon" ... the dev-branch changelog isn't mentioning it at all.  Did this slip in by accident and / or can we expect it to be updated soon™? Share this post Link to post Share on other sites
DnA   5143 Posted September 18, 2020 On 9/13/2020 at 10:03 PM, lexx said: Did this slip in by accident and / or can we expect it to be updated soon™? The black P07 is part of a few 2.00 reskins were adding. It has the correct inventory icon in the internal version. We've had Dev-Branch paused for some "logistical issues", but look to resume it soon (along with the 2.00 RC) 😎 9 Share this post Link to post Share on other sites
fn_Quiksilver   1636 Posted October 7, 2020 impressed with the script commands coming, thats a lot! 1 Share this post Link to post Share on other sites
lexx   1363 Posted October 11, 2020 Did something happen with the default marker alpha values? For some reason all my default black markers seem to have more transparency now than before... sadly I can't post before/after screenshots, but I'm 100% sure something has changed. Share this post Link to post Share on other sites
x3kj   1247 Posted October 13, 2020 whooho update 👌 Quote Added: elevatePeriscope script command  @Dedmen @killzone_kid Would it be possible to add 2 more script commands that do the same for turret elevation and traverse? Because right now (unless i missed something) you cant directly influence turret/gun orientation via scripts on non UGV turrets - but it would be super useful to have for fire control systems, or the "simple" feature where a gun (e.g. artillery) has to elevate to horizontal before reloading and then back again... Or custom turret damage (e.g. gun being stuck in last position, rather than the "sad barrel" feature) Yes one can do some dirty tricks with piling animations on top of each other in the model as workarounds, but it gets complicated and dirty (hiding/unhiding copies of the turrets just so you can remove user inputs etc, including turret indicators etc). 3 1 Share this post Link to post Share on other sites
Dedmen   2700 Posted October 14, 2020 20 hours ago, x3kj said: Would it be possible to add 2 more script commands that do the same for turret elevation and traverse? Feel free to just make FT tickets about it, that way we can more easily track progress or questions or whatever there might be. We will probably look into that though, see how much work it might be to do that, we'll see. 2 Share this post Link to post Share on other sites
Dedmen   2700 Posted October 14, 2020 On 10/11/2020 at 8:36 AM, lexx said: Did something happen with the default marker alpha values? For some reason all my default black markers seem to have more transparency now than before... sadly I can't post before/after screenshots, but I'm 100% sure something has changed. createMarker script command creates the Marker in the "Global" chat channel, so in MP you can switch over to that and will see that. But yeah i think that's the issue, I think it should be channel-less by default, not Global Channel by default. 3 Share this post Link to post Share on other sites
lexx   1363 Posted October 14, 2020 I never even realized there is a channel function for markers ... guess it shows that I never bother with multiplayer stuff. /Edit: Oh, it's a new addition. Well, then no wonders. Just sucks that I didn't noticed it earlier. 😆  Anyways, I noticed that BIS_fnc_stringToMarker doesn't seem to have a channel argument at all.  Other than that, I would support markers to be channel-less by default, like before. Share this post Link to post Share on other sites
pierremgi   4853 Posted October 14, 2020 And, if I remember well, any local marker (scripted) needs ALL marker commands local. If one of them is not local, the marker falls into global channel. Share this post Link to post Share on other sites
Dedmen   2700 Posted October 15, 2020 Nah its not new. Has always been a thing with player placed markers in Multiplayer. Yes, any non-local command transmits the full marker state via network. If you create markers via script, I'd recommend configuring them with local only commands, and only using a global command for the last change.  22 hours ago, lexx said: Other than that, I would support markers to be channel-less by default, like before. Yeah already fixed for next dev-branch update. That was not intentional. 2 Share this post Link to post Share on other sites
samatra   85 Posted October 18, 2020 It seems that last update broke 6.5 suppressors, camouflaged ones muzzle_snds_H_MG_blk_F, muzzle_snds_H_MG_khk_F don't seem to work anywhere anymore. muzzle_snds_H_SW no longer works with MX SW, only with Mk200 (if its deprecated copy of muzzle_snds_H_MG, it should still function the same). Mk200 takes base muzzle_snds_h suppressor, not colored ones, same with Katiba.  Compatibility table for all 6.5 suppressors with all 6.5 weapons: https://pastebin.com/raw/6GgBsVkh (view without text wrapping)  Screenshot of table above: Spoiler  1 Share this post Link to post Share on other sites
x3kj   1247 Posted October 18, 2020 On 10/14/2020 at 4:15 PM, Dedmen said: Feel free to just make FT tickets about it, that way we can more easily track progress or questions or whatever there might be. We will probably look into that though, see how much work it might be to do that, we'll see. There it is https://feedback.bistudio.com/T154411  i'm going to use this opportunity to throw my older tickets regarding weapons at at the wall, in the hope that something sticks 1) Bug - model of "shotShell" simulation projectiles is not displayed for initspeeds> 330m/s .  See 1st part of this ticket https://feedback.bistudio.com/T125167 shotBullet is no alternative, as model does not update orientation with current projectile vector. Rockets display correctly but are less than ideal because of weird ballistics and require submunition for penetrations.  2) Explosive hit propability feature to tone down unrealistic artillery lethality - https://feedback.bistudio.com/T116969 (part of "the big bad four" issues in damage modeling https://feedback.bistudio.com/T120542), Dslyecxi agrees btw 3) Feature to support weapon systems with multiple synchronized/ alternating fire , and/or high burst rpm but low mag capacity - https://feedback.bistudio.com/T123542 currently only possible with using lots of magazines (which leads to problems in performance or AI (cant remember) - reyhard alluded to this) 4) Feature for variable Ammo per Magazine (mixed ammo belts) https://feedback.bistudio.com/T82246 5) Bug - Explosive shells can explode multiple times, when deflecting of something -> suggestion to prevent explosion in case of deflection. Other nice to have's included. https://feedback.bistudio.com/T82243 6) Optimization (maybe) - handleDamage EH fires for every hitpoint of the vehicle instead of just damaged hitpoints https://feedback.bistudio.com/T124814 2 2 Share this post Link to post Share on other sites
killzone_kid   1330 Posted October 20, 2020 On 10/18/2020 at 10:19 PM, x3kj said: Optimization (maybe) - handleDamage EH fires for every hitpoint of the vehicle instead of just damaged hitpoints https://feedback.bistudio.com/T124814 backward compatibility nightmare, not happening Share this post Link to post Share on other sites
x3kj   1247 Posted October 20, 2020 it was never documented... but i can understand - its not so important in the grand scheme anyhow Share this post Link to post Share on other sites
killzone_kid   1330 Posted October 21, 2020 11 hours ago, x3kj said: it was never documented... This is not true, please do not try to mislead. From wiki:  Quote Note: Currently, in Arma 3 v1.70 it triggers for every selection of a vehicle, no matter if the section was damaged or not).  Share this post Link to post Share on other sites
x3kj   1247 Posted October 22, 2020 Apologies, then i was simply out of date. Didnt check wiki since i made that ticket. Share this post Link to post Share on other sites
lexx   1363 Posted October 27, 2020 Looks like my project is crashing the game since today's dev-branch update when trying to load 3den. First I thought it might be something with the terrain itself, but it loads up in the main menu (background) just fine.  Thing is, I can't really see what's causing it right now - but it stops crashing when it's not activated. Also, it does *not* crash on 3den load when running the game via arma3diag_x64.exe ...  Anyone got any ideas how I could debug that? The .rpt file stops with that: c:\bis\source\dev\futura\lib\network\networkserver.cpp ClearNetServer:NOT IMPLEMENTED - briefing! Extensions: c:\bis\source\dev\futura\el\multicore\jobs.cpp(23) : Assertion failed '_jobState<JSWaiting || _jobState>JSSuspended Not sure if it's related, though.  /Edit: It just crashed in 3den even with the arma3diag_x64.exe - just took a while longer.  \/Context: [] L1 () [] L1 () [] L1739 (A3\functions_f_bootcamp\Inventory\fn_arsenal.sqf [BIS_fnc_arsenal]) [] L4795 (A3\functions_f_bootcamp\Inventory\fn_arsenal.sqf [BIS_fnc_arsenal]) [] L4797 (A3\functions_f_bootcamp\Inventory\fn_arsenal.sqf [BIS_fnc_arsenal]) [] L83 (A3\functions_f_bootcamp\Inventory\fn_saveInventory.sqf [BIS_fnc_saveInventory]) [] L83 (A3\functions_f_bootcamp\Inventory\fn_saveInventory.sqf [BIS_fnc_saveInventory]) unable to save config variable to: ======================================================= ------------------------------------------------------- Exception code: C0000005 ACCESS_VIOLATION at 90DA2104 Version 2.01.146823 Fault time: 2020/10/27 17:43:54 Fault address: 90DA2104 00:90DA2104 Unknown module Prev. code bytes: 0F 84 0E 01 00 00 83 7F 08 00 0F 85 F8 00 00 00 Fault code bytes: 48 8B 03 48 8B CB FF 90 A8 00 00 00 84 C0 0F 84 =======================================================  /Edit2: The crash is not 3den related. If I boot up the game (map loads in the background) and then start any scenario, the game will crash. I think this is the reason why it doesn't crash with the diag.exe right away - I've set the game here to start without any terrain pre-loaded, so booting up 3den will load the terrain for the first time (PS: The crash happens on any other terrain as well, not just my own). However, I have not yet been able to reproduce this in vanilla arma. 😕  /Edit3: My theory was correct. Booting up the game with an empty world will not result in a crash when starting 3den with the normal a3.exe file. /Edit4: Just reverted to latest stable to make sure and yup, the game won't crash here. Share this post Link to post Share on other sites
Dedmen   2700 Posted October 27, 2020 @lexx -showScriptErrors (the script context logging above) is broken but already fixed, but was fixed shortly after we prepped dev branch. the jobs assert is weird. But probably also my fault 😄, but could also be caused by -showScriptErrors  Maybe try the Arma exe from profiling branch, that is newer and probably has the issues fixed, though no diag binary on there. 1 Share this post Link to post Share on other sites
samatra   85 Posted November 1, 2020 On 10/18/2020 at 11:08 PM, samatra said: It seems that last update broke 6.5 suppressors, camouflaged ones muzzle_snds_H_MG_blk_F, muzzle_snds_H_MG_khk_F don't seem to work anywhere anymore. muzzle_snds_H_SW no longer works with MX SW, only with Mk200 (if its deprecated copy of muzzle_snds_H_MG, it should still function the same). Mk200 takes base muzzle_snds_h suppressor, not colored ones, same with Katiba.  Compatibility table for all 6.5 suppressors with all 6.5 weapons: https://pastebin.com/raw/6GgBsVkh (view without text wrapping)  Screenshot of table above:  Reveal hidden contents  Wrapped this up into a ticket, also added issues with 7.62 suppressors: https://feedback.bistudio.com/T154769 1 Share this post Link to post Share on other sites
lexx   1363 Posted November 6, 2020 Is it just me or are the wheels of the UGV broken? They won't turn left/right. Share this post Link to post Share on other sites
1212PDMCDMPPM   200 Posted November 7, 2020 Hello, I don't quite understand how getAttackTarget is working. When is it reseted ? If I make an AI flee the area, it's still giving me the same result. If I use forgetTarget to make sure the attacker is forgetting what unit he was engaging, getAttackTarget is still returning the same result.  Thx ! Share this post Link to post Share on other sites
