Sniperwolf572
-
Content Count
3304 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by Sniperwolf572
-
I'm gonna pull the age old "look at these BHD stills" move and argue that not even Hollywood goes to the point of making the "spec-ops chopper" co-pilots go in a state of "I'mma gonna shoot me some things" unless they're in dire need. :p I believe that there's a reason the seat is a co-pilot seat, that most helicopters are actually operated by two people and that one of the reasons isn't "so the other guy can shoot his 9mm". While I also love the feature, and I'll agree that the possibility is there to do so when necessary, I'm just questioning the default state of those pilots. Making the 2 guys in the back FFV when appropriate would also get my vote as it makes more sense for them to shoot things if necessary.
-
It's a great feature, but there is a problem this type of change has made, helicopters are much worse in regards to this, while the commanders of tanks could be forgiven for this. xH-9 Helicopter copilots are now always in a type of a "I'm soooooooo ready to fire out of this helicopter" when not actively piloting if they have a weapon, which doesn't make sense for a copilot, at least to me. Especially considering that they now have MORE capability to fight back as a crewman with a job in there, than the first two cargo seats which are just casually sitting there. It makes the copilot appear rambo at all times. Reference to "Drawdown 2035" and "Rising Tensions" missions as they are now. Co-pilots no longer seem like they're actually focused on doing their job of co-piloting, but as if they're going target hunting and they just find that seat better than the bench. Sure, this will get fixed by the mission makers when they don't want such behavior, but in the end, as a player or AI, you no longer have an option besides acting like a copilot UNLESS you get rid of all your weapons. The "offensive co-pilot" should be a switch from your default stance to "ok, defending the helicopter with my pea-shooter is now more important than actually helping the pilot do his job". There is no way for a player or AI to "stand down" as a copilot and act like before unless the mission maker specifically uses enablePersonTurret on them. The benches are ok with the current system of "weapon down (default) <-> weapon up" as historically they've always been in a "weapon down" state even before FFV, and it makes sense for them, but copilots actually need 3 state system to make it "sane", "hands on the controls (default) <-> weapon down (hmm, I might need to defend the chopper) <-> weapon up". The least amount of work would probably be to make the "hands on the controls" a default state when the weapon is down, and the transition to "weapon up" when "raise weapon" is pressed. Sure, we lose the cool weapon down pose, but, eh. Edit: Also a bug that this has introduced is that the co-pilot no holder holds the controls of the helicopter in first person view when unarmed (rendering issue I suppose, body rendered after the helo with no depth checks). And when armed, the co-pilot has the cyclic stick in his leg
-
Oukej asked this: And that was my reply to this specific point which suggests that the compartments could be "compartment-agnostic" in the future.
-
In my opinion, only switchable seats should be the ones in the same "compartment" as your current seat. For example, people in the cabin of the HEMTT shouldn't be able to switch to the flatbed area of the truck, and vice versa. Whatever you decide in the end to be the defaults for this, i think that this should be made customizable by the mission makers/scripts, like a possibility to lock a seat to switching. In certain cases, you don't want players switching seats, going between turrets, etc. For example, as it is currently, sometimes you want to lock the gunner positions on the Ghosthawk, but putting AI in there allows the players in cargo to switch to the gun, even if the AI isn't the part of the players group. On the other hand, sometimes, this is actually desireable behavior.
-
Creating Custom Key bindings
Sniperwolf572 replied to bull_a's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
Both of those addons use the keybinding interface that CBA introduced, but it has certain limitations due to certain issues with the event handlers. Instructions on how to implement it in your addon/script can be found here. A native way to bind controls to actions does not exist, and you can express your dissatisfaction with that here. -
Same here.
-
Arma 3 Roadmap for 2015. Likes & Dislikes.
Sniperwolf572 replied to esfumato's topic in ARMA 3 - GENERAL
It's said in context of the launcher. A dependency is "Addon A requires addon B to work". This is usually handled in a way so when you download addon A, addon B is also automatically downloaded because addon A depends on it to work. Currently, this is not the case within the launcher. -
using getvariable to access namespace data created by bis_fnc_saveinventory?
Sniperwolf572 replied to Tankbuster's topic in ARMA 3 - MISSION EDITING & SCRIPTING
You need to look for the entry within the bis_fnc_saveInventory_data, as that is a big array containing all the loadouts. I'm not 100% sure what the structure of that array it is right now as I can't check right now, but I'm assuming is an array of pair entries so try accesing it like so. // uiNamespace since you're saving it there, profileNamespace usually for loadouts from Arsenal [ (uiNamespace getVariable "bis_fnc_saveInventory_data"), "test"] call BIS_fnc_getFromPairs; Edit: It should be, according to past me. :p -
You were and are able to flip all kinds of vehicles upside down and on their sides since forever and exit them without a problem.
-
The Community Branch - Serious Topic, Serious Idea, Serious Fun.
Sniperwolf572 replied to CaptainAzimuth's topic in ARMA 3 - GENERAL
Well, technically it's not impossible. But it's certainly not practical considering the solutions which are already in place. :) -
The Community Branch - Serious Topic, Serious Idea, Serious Fun.
Sniperwolf572 replied to CaptainAzimuth's topic in ARMA 3 - GENERAL
The rabbit hole goes deeper, a lot of addons contain work of others, at times even outside our community, where the author has gained permission to use the content as a part of their mod. Oh boy. A piece of general advice, don't label yourself as an "ideas guy". Even the skills you listed have nothing to with what work of this magnitude would entail, as the content has already been created, it's mostly administrative/deployment/testing work. And what the idea guys usually miss, are the details which make the idea so much more complicated than sitting down and saying "Let's do this" and then looking around the room. In the end, this would be a massive effort to solve a singular problem to which the solution(s) already exist. I see no reason why PlayWithSix's simple concept of "Create a mod preset" -> "Add mods to the preset" -> "Press Install" requires reinventing to a highly rigid Steam branch which would bloat out of proportions. Even the Steam Workshop itself has the ability to create public/private collections and moderate them, the only limitation there currently is that it's not very welcoming of bigger mods and certain other things which rub people the wrong way. I don't even want to imagine how big of an performance impact would be just by the overhead created by loading in a massive fuckton of addons into the game. -
Yes, it's being prototyped. You can find some info here in the "Platform Updates" section. If you missed that article entirely, it's a good read.
-
3D Editor is some epic love. I don't even care if they make me type in the classes manually in it.
-
Discover, Play, Promote missions and mods withSIX
Sniperwolf572 replied to sickboy's topic in ARMA 3 - GENERAL
Considering the news above, are there any plans to have a standalone repo manager tool that's not tied to that old beast Six Updater? -
findDisplay question
Sniperwolf572 replied to MrCopyright's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Checks to see if it's open. -
Dedicated server moveInCargo, BIS_fnc_MP, locality
Sniperwolf572 replied to Sniperwolf572's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Alright, figured it out. Turns out that it's possible for moveInCargo to assign multiple units to the same cargo index in MP if executed one after another with varying localities, and that's where the command failed I suppose. I believe the reason it worked for the leader but not subordinates I guess is simple, leader ended up being first in the array. There were no occupied spots in the vehicle at the start and additionally the AI subordinates where then local to the player leader. I believe the reason it failed when the player is a subordinate is that the AI was local to the server, was moved there just before the remote player unit also tried to move in the same slot. Executing the command a second time, the AI units were already in the vehicle, and appropriate cargo index was used. In the end, using "_x moveInCargo [_vehicle, _forEachIndex]" removed the chances of identical index and resolved the issue. -
Dedicated server moveInCargo, BIS_fnc_MP, locality
Sniperwolf572 replied to Sniperwolf572's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Tried it already earlier. The only difference it makes is that with it, when I do manage to be put in the vehicle, I'm not ordered out of it right away. I'll try the other ones, but I'm confused what makes the first execution of moveInCargo to "fix" the ones following after it. -
MMGs = Micro Machine Guns obviously!
-
Discover, Play, Promote missions and mods withSIX
Sniperwolf572 replied to sickboy's topic in ARMA 3 - GENERAL
Didn't get a chance to try it earlier, but seems to work ok now. Tried with a few random addons. Edit: Spoke too soon I think, same symptoms. -
I fully appreciate the time it takes and never in a million years would I claim "not enough interest". The main case is that changes like this aren't something that's often tackled within a product cycle, and I'm basically trying to point towards what I see is the most optimal way. Others seem to be keen on it too. Besides, the current change did pop out of the blue, maybe not for you since you guys obviously had enough time to set the values for each weapon, but I'm certain for the rest of us it randomly showed up in a dev blog and we all collectively popped the MGS style exclamation marks. :p This is a great summary of what's going on here.
-
Just because we're looking at the issue from a different point of view, does not mean what I said is invalid. At least I don't see how it becomes invalid. No powder and lower power of the ammo were just examples, it also affects the higher power ammo. With the current implementation, in all those cases, the bullets are fired at the appropriate speeds defined by the ammo. The change you made makes those values irrelevant if the weapon defines it's own init speed. The only type of weapons that I know that behave sorta this way are railguns, catapults, slingshots and so on, which propel the projectiles themselves (and even there I guess there is variance depending on the mass of the projectile, even without a combustible propellant). Hopefully the feature that requires this kind of an approach will be announced soon so we can have an open discussion about it and potentially propose better solutions rather than just us being shut down by "you don't know what we're doing" arguments. As things stand, from the information given to us, this is where we stand. Currently the system is: The thing you load in the weapon determines the speed it leaves Weapon has no effect on it Muzzle attachments can affect it via multipliers What the future looks like with your current implementation: The thing you load in the weapon has no effect on the speed it leaves Weapon determines the speed no matter what you load in it. Falls back to the implementation above on negative values or a missing definition Muzzle attachments can affect it via multipliers What is proposed by the community: The thing you load in the weapon determines the base speed it leaves Weapon can affect it via multipliers Muzzle attachments can also affect it via multipliers Currently impossible and will continue to be impossible unless implemented I'll make a little tool to illustrate this more vividly.
-
I'd love the hear the explanation how it makes sense? From where I'm standing, you're basically limiting your weapons to never be able to fire ammo with less "punch". As a silly example, imagine a bullet with no gunpowder at all in it. Your logic is that it should still be fired at the velocity of a normal bullet because the barrel says so. Not everything is a railgun.
-
Discover, Play, Promote missions and mods withSIX
Sniperwolf572 replied to sickboy's topic in ARMA 3 - GENERAL
Your DE mirrors seem to have gone to shit. Random files seem to get stuck at 0% when downloading from there, and the download speed seems to be really slow. I've been hearing similar reports from others. I've tried AIA_TP and two RHS packs, and they failed on seemingly random pbos within their downloads. I had to resort to blocking their domains through hosts as I couldn't find any built in way to force a mirror. App then fell back to the US mirrors which had better download speed than the DE ones ever did for me and had no issues. -
Feedback tracker administration
Sniperwolf572 replied to bis_iceman's topic in ARMA 3 - DEVELOPMENT BRANCH
Can someone please try and confirm that it's actually fixed so we can mark it as resolved. I don't have access to Arma at the moment. :) -
Does it happen on all "islands"? If you aren't doing this already, try the VR map and Stratis and see if it happens there. I remember some tests done with very large maps producing such artifacts. The larger the island and the further away in the top right corner you are, the bigger the effect.