Sniperwolf572
-
Content Count
3304 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by Sniperwolf572
-
setTimeMultiplier?
-
Imagine you have a base game rifle class MY_Gun. Base game MY_Gun has a semi auto and burst fire modes. Mod A inherits base gun and inherits burst fire mode from MY_Gun and changes it to burst 5 bullets instead of 3. Mod B accidentally removes burst fire from MY_Gun. Error goes "MOD_A_gun has a problem because burst fire does not exist". The problem is because Mod B removed the burst mode. Yet you go to Mod A to complain and waste their time because the game simplified the issue to tell you it's their fault.
-
One thing nobody seems to be mentioning is that we have recently just broke a record between the release of two ArmA games (excluding the OFP -> A1 period) and are bound to break the OFP -> A1 gap. In two months time, we're going to enter 4th year of hands-on ArmA 3, previous record being 3 years, 8 months for A2 -> A3, and there is still another year of ArmA 3 to go at minimum by looking at the roadmap. If Tanks DLC releases sometimes in Q1 2018, that's going to be 5 years of A3 easy. Assuming ArmA 3 support completely ends at that point, Arma 4 isn't going to be released some months after that. Barring some kind of a miracle, next Arma title might probably even break the OFP -> A1 record. At this point in the last cycle, we were two months into messing with A3 alpha, and have spent at least year of seeing trailers, screenshots and flooding the Arma 3 suggestions forum. So damn right it's starting to feel stale, average Arma nut has spent at least 1000 hours on Arma 3. We've spent more than 7 years on Chernarus (and we still seem to want more of it looking for the calls of DayZ Chernarus to be ported to A3), 3 of them trying to run away from Altis. We're about to start the 5th year of the most technologically advanced, communicative and supported ArmA game which also missed the mark on the era and assets community favors the most.
-
This exact same thing happens to me when trying to pick Area marker color as well, except that dialog can't be scrolled. Icon marker color works fine.
-
Helmets have straps to prevent that from happening, along with not falling off when running and so on.
-
64-bit Executables Feedback
Sniperwolf572 replied to Richard.biely's topic in ARMA 3 - DEVELOPMENT BRANCH
That's true, however, they only recommend that if you want to squeeze more lifetime out of the SSD. For the best performance, they still recommend to leave Windows to do it's thing with pagefile. -
Jets - Sensor overhaul (Radars, IRs, Lazors, PGMs)
Sniperwolf572 replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
I think he means the secondary downward pointing camera that can be opened with Ctrl+RMB. Sling Load Assistant is already a part of the custom info. -
Jets - Sensor overhaul (Radars, IRs, Lazors, PGMs)
Sniperwolf572 replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
While I agree that every key on my keyboard seems to do something in Arma, in this case I think it's acceptable, as the boxes in the UI where sensors show up anyway are controlled by 5 additional different keybinds. You're not gonna jump in the plane and know what the radar does without someone explaining it to you anyway. Improving the first person cockpit experience would be awesome, because even the current HUD/MFD's as is, are unreadable when flying without zooming in. You can tell what a few elements are, but between the zooming in and out based on speed, and the tiny scale, cockpits are really hard to deal with. Sometimes I wish I could incrementally zoom to some point other than 0% and 100% so I can read the HUD and fly the plane. Great majority of the action problems in this game could be solved (and immersion increased) if we could just bind actions to model selections then activate them by pointing at them and pressing a button. But alas, let's not do that because of reasons. I'm absolutely certain I could make a proof of concept for these kinds of actions anywhere as a mod, let alone doing it with full engine access (Fluid Door Opening already does majority of work needed for this). But hey, I guess it's easier for players to deal with the clutter of the current, janky, spastic action menu. -
64-bit Executables Feedback
Sniperwolf572 replied to Richard.biely's topic in ARMA 3 - DEVELOPMENT BRANCH
Because memory usage doesn't work that way. What you are saying is "I have this movie in my hard drive, I open it up in 50 media player windows and play it at the same time, it's still taking up the same amount of room on my hard drive". Think of RAM as incredibly fast storage, game stores things into that storage so it can access it faster without having to talk to really slow storage that is SSD's and HDD's. The RAM usage is "stuck" because there is nothing else to load in there, fly around that same island, and you'll see RAM usage skyrocket. Increase your viewdistance, and so on. More RAM isn't gonna do anything in the cases which you are describing because it's like saying more seats in the car equals to faster max speed. A single smoke particle takes up a negligible amount of RAM, so does a thousand of them, however performance impact comes from having to show them on your screen, determine how they overlap, and so on. -
Jets - Sensor overhaul (Radars, IRs, Lazors, PGMs)
Sniperwolf572 replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
I think it's in a bit of a WIP state at the moment, to integrate them into the MFD's themselves. From what I can tell, it's only available as a UI element in the targeting pod (very hard to do anyhting with it there tho). Buzzard seems to have it implemented for the cannon in the MFD as a dashed circle, but the rest of the planes don't. For CCIP, they are still implementing the dummy approach which links the center of the MFD with the indicator that shows predicted flight path of the plane (can't recall the technical name for it). -
Jets - Custom Panels (GPS, Camera feeds, ...)
Sniperwolf572 replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH
You shouldn't feel bad, there is a problem with the GPS, but it's very hard to notice right away as the GPS UI/UX is horrible. What made you think it's upside down is the following: The markers don't preserve direction. An arrow marker pointing north will always point up on the rotating GPS, meaning if you fly south, it will point south. You can see it in your picture, WP 5 is pointing south, yet on the minimap it's pointing north. Area marker that is wider than it is taller will rotate as you rotate making absolutely no sense. (Simple solution here is to not rotate marker bodies, just the labels if there are any.) The GPS itself is very hard to read, especially when you're moving and especially now that the GPS is moving as well: Everything is transparent with samey colored lines. It's hard to tell at a glance what's roads and what's elevation lines, what is ground and what is sea. Text is mostly dark on a dark background with absolutely no contrast. GPS zooms in and out automatically based on speed, and it hard to keep track of what's going on, especially in things like helicopters that can vary their speed a lot. Let's just say that there would be a lot of lost people and fatalities if it was a real life commercial product. BI, plz fix. -
While I have no stake in either end of the argument, and couldn't care less about KoTH or it's balance, that argument is against everything Arma stands for, and besides, you already have multiple things that behave against what you argue for. Turning off NVG support in optics, turning off TI in optics, changing mass and center of mass which affects control, disabling and tweaking stamina parameters, limiting a vehicles speed, and so on. While sure, nobody is stopping anybody from creating a new config mod and removing the CCIP, there is a very real case why many authors wish to be able to create new classes for their missions, or change things like this on the fly to tweak certain small things about already existing classes/assets which cannot be done by scripting but it's absolutely insane to induce an addon dependency. And scripting itself can already change how a lot of game systems behave from default to make them absolutely unpredictable. The very real use case is that sometimes you want to do things which are only possible by tweaking the config and creating an addon dependency, but you absolutely do not want to make your mission addon dependant, because that's the difference between being accessible to anyone vs. installing mods and reducing your audience to only those who can be bothered to do so. Having the ability to create new/child classes through something like description.ext for this very purpose would be a godsend. Needing to have a plane without CCIP, a differently textured vest or a weapon, and so on. Why is it OK to to be able to make a gun that shoots tanks on the fly without touching the configs, but not change that guns texture? Why is it OK to to be able to remove NV/TI capabilities from a vehicle, change it's center of mass on the fly, but not remove CCIP indicator? Where is the predictability in that? Should we not be able to replace bullets with tanks for the sake of predictability? There is always more need for more customization like this in Arma, it's what makes it great. You can have Argo for predictable.
-
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
This should've been simply fixed by better presentation, something BI is horrible at. A "release control" keybind and proper localization of the action menu entry. Maybe even more of an on screen text that says "Press KEY to release control" They already tried to make it clear you're remote controlling with the laughably vague vignette around the edges. I don't see how it was better to do anything else than remote control, preserving the player context for the player Zeus is beneficial. As is for all the other possible cases of remote control, other than UAV and Zeus. What's the point of solving it differently when you have a perfectly functional way to do it. There'd be more workarounds needed if player context switched rather than how it is now. Same here, I guess this is one of those situations where we have to agree to disagree. I agree there are things to be fixed with various commands, but I don't see this specific thing as one of them. However, identity, view and control contexts seem perfectly logical to me, and I really dislike the fact that I'm arguing with clear examples of usage, solutions and beneficial points of current behavior and all I get back is "no, you're wrong, hacked, abused, broken". All I'm asking is to provide me a better way to do what was shown in the image I've illustrated, that gives you more freedom and control, than what is currently given. The question is so simple, why do you think it's better/beneficial if player variable becomes the driver logic of the UAV and why is it better if the player variable becomes the remotely controller Zeus unit after using "remoteControl". I've clearly given you why I think it's better it does not. You have a command framework for switching all those contexts, and you want to shove them all into one due to ignorance on how to use them instead of expanding them so they work solidly. As for your references to history, I'd appreciate it if you actually linked something, I can't find anything in CIT related to selectPlayer or remoteControl with any of Sumas comments and Biki only shows things not relevant to what we're talking about. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
I disagree, while playerControlled doesn't exist, the alternative way of reading the remote control unit of those features via the variable was the was there for the start. Remote control for UAV and for Zeus is perfectly fine because it is what is happening, and the reality is, when you need a feature to control a different entity, in majority of the cases in this game you want remote control. While for cases like team switch, selectPlayer is what you want. Just because an author expects player to work one way, and it doesn't, doesn't mean the command is at fault. It's the same exact thing like dividing something and forgetting that division by zero will error out, and then arguing that when dividing by zero, zero should actually be treated like 0.00000000000000000000000000000001 because many authors forgot to account for that possibility. The ugly hack, that you describe, is solely due to lack of playerControlled (or any other command that would return you the destination unit of "a remoteControl b") and the necessity of actually exposing it to authors. Look at the picture presented above and tell me how setting the player to anything else than it is in the picture is a sane option. Who is "player" for you there? -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
Anyway, just to bring my point across why playerControlled should absolutely, most definitely exist, you can set up this simple situation in the game right now with two lines of code. It's absolutely beautiful that we can do this right now. a remoteControl b; c switchCamera "External"; -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
Ok, but the bold part is not clear to me. Why do you think client "identity" and client "control" should be combined into a single "player" variable? What is not working out of the box? Even if we were at step zero and started from scratch, to me it would still make much more sense to have "player" return the "identity" of the client, while something like "playerControlled" returned the control of the client. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
If this is aimed at my comment, I'm not sure you understood what I meant. I don't expect the mission to end when using remoteControl. This is how I expect the system to work: player - The "man" unit the player contextually is (working as intended) selectPlayer - Change the player context (working as intended) playerControlled - Whatever "man" unit the players controls are bound to (missing, necessary, should not behave the same as cameraOn) remoteControl - Change the control context, in turn changing playerControlled (working as intended, minus playerControlled not existing) cameraOn - Whatever the camera is attached to (working as intended, but is not what playerControlled should be) The problem with cameraOn is: // Situation: player is driving a vehicle cameraOn === player // returns false cameraOn === vehicle player // returns true Which is what commy2 is saying. Just because you are remote controlling a different unit, the context of "you" that the player provides should not change. If you truly wish to switch the player context, selectPlayer is already something that exists. Zeus remote controlling an AI soldier, a soldier remote controlling a UAV pilot, and anything remote controlling anything, should not change the context of "player" away from his actual unit, just the playerControlled. That's why it's called remote control in the first place, because you are remotely controlling something, not because you have become something. It's why it was implemented and why it exists even though selectPlayer existed for a long time before. selectPlayer on the other hand should change the context of player, which clearly indicates that you, indeed, have become somthing else. By leaving things as they are, and introducing playerControlled, you have full control of what you actually want to happen and the behavior is well and truly defined. There is no room for ambiguity. "player setDamage 1" - The simplest problem you have with changing player. I wanted to kill the player there. Not the UAV pilot they're in control of, not their remote controlled body. "playerControlled setDamage 1" - I wanted to kill either the player or their remote controlled unit. In reality, this would rarely be what anyone would want to do. "player === playerControlled" - Gives me the information if the player is having an out of body experience (remote controlling something). "if (player != playerControlled) then { playerControlled setDamage 1}" - Is a clear and fully reasonable code that I wanted to kill the players remote controlled unit (be it UAV or anything else) and not the player himself. And so on. Just switching the player mindlessly to whatever he is in control of will cause many more problems than it will solve, especially with all the existing scripts. To me, in an insane example, arguing that player should change to remoteControlled unit is like arguing that when you control an RC car in real life, your consciousness should move to the RC car. TLDR: playerControlled is absolutely necessary, cameraOn is not a solution, player should stay as is. @commy: Can you clarify why you think changing player instead of adding playerControlled is better? @killzone_kid: If cameraOn === playerControlled at all times, then that's a problem with playerControlled or cameraOn not doing what it should do, not an argument that playerControlled shouldn't exist.- 1481 replies
-
- 1
-
-
- branch
- development
- (and 2 more)
-
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
While I agree it's shitty to do the whole getVariable dance in that case, but if anything, player command shouldn't be touched for what it does. There are many things that depend on player actually belonging to the context of "you" belonging to the player unit. Switching units with selectPlayer actually switches your "you" player context in a very meaningful way which should absolutely not be used for remote control. Simplest example is if you selectPlayer something, and the old unit dies, you do not expect to see a death screen. While remote controlling, it's the opposite. If remoteControl behaved as selectPlayer in that case, theoretically you could continue remote controlling something when your original unit is dead. And then you'd have to account for such cases, and who should be the one accounting for it, etc.There are so many similar problems for such a thing. This would be much better solved with a new command, which was tailored for the problem, which returned the Man/Logic that the player is actually currently controlling, something like cameraOn, maybe controlsOn, whatever. cameraOn also shows the specific problem that I'm talking about. Yes, you are controlling the vehicle you are the driver of, and the camera is attached to the vehicle, but contextually, "you" is still the unit inside of it. Writing a macro for the thing you want after that is a trivial thing. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
I can't think of any actual practical use in Arma other than for bitflags that they added. Bitflags is basically useful if you need to pack a bunch of boolean properties. Bitflags are used for certain things in Arma configs like AIAmmoUsageFlags or weaponLockSystem. Imagine you have 3 booleans to describe an animal. Let's say canFly, canSwim, canWalk. Each of those can be represented as a 0 or 1. Binary Decimal Description 000 0 Can't do anything 001 1 Can fly 010 2 Can swim 100 4 Can walk 110 6 (2 + 4) Can swim and walk but not fly 111 7 (1 + 2 + 4) Can do all So instead of having canFly = true, canWalk = true, etc., you pack them into a single int which you can read from. So knowing that, you can use BIS_fnc_bitflagsCheck to see if the AI will use some ammo against air targets: private flags = getNumber (configFile >> "CfgAmmo" >> "MyAmmo" >> "aiAmmoUsageFlags"); private aiCanTargetAir = [flags, 256] call BIS_fnc_bitflagsCheck;- 1481 replies
-
- 4
-
-
- branch
- development
- (and 2 more)
-
I've exaggerated the image a bit for those who still can't see the difference to better illustrate it. Hopefully it's pretty obvious now how much color banded the shadow is on the left side and how it's hardly noticeable on the right. The texture under the shadow is not affected, just the "shadow layer". As you can see, the left side looks like a block of Kit-Kats before you've eaten them, while the right side looks like that same block of Kit-Kats the day after you've eaten them.
-
How much can this 64bit executable help?
Sniperwolf572 replied to Frankdatank1218's topic in ARMA 3 - DEVELOPMENT BRANCH
To quote a certain popular article that puts this in perspective: Time Relatively the same as ------------------------------------------------------------- 1 CPU cycle 0.3 ns 1 s Level 1 cache access 0.9 ns 3 s Level 2 cache access 2.8 ns 9 s Level 3 cache access 12.9 ns 43 s >> Main memory access 120 ns 6 min >> Solid-state disk I/O 50-150 μs 2-6 days >> Rotational disk I/O 1-10 ms 1-12 months Internet: SF to NYC 40 ms 4 years Internet: SF to UK 81 ms 8 years Internet: SF to Australia 183 ms 19 years -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
What you're asking for is incredibly arbitrary and context sensitive. Functions are a thing. You can combine a ton of existing checks, in any way you want, into a short and simple one liner way better for your purpose than what you are proposing. -
I'm glad you're revisiting deployment, I agree with whoever thought that it can be further enhanced. As for the automatic undeploy, I think this is a perfect example of feature to put in as a user option. General gameplay is not affected and some people might like it if it worked that way, some might not. I don't see what the fuss is about, as long as it isn't forced to behave that way.
-
Forums migration/update status items
Sniperwolf572 replied to BohemiaBeck's topic in BOHEMIA INTERACTIVE: Web-Pages
This has become an issue for me too today after upgrading to Chrome 52. It's a problem with inline items rendering inside inline-block items. Quick fix for this is to do one of these two: // Add this table.ipb_table .subforums.ipsList_inline > li { display: inline; } // Or add this table.ipb_table .subforums.ipsList_inline > li > a { display: inline-block; } Solution #1 breaks lines whenever but fills the space better, solution #2 breaks lines to keep a subforum in the same line. And can we please, finally, after a year, link the lock icon on the locked forum threads with "?view=getnewpost". All the important stickied threads that are locked like dev changelogs, SITREPs and whatnot are annoying to follow because you have to manually find new posts. -
Thanks, I'm aware mods for this exist. However why I'm saying this here is because an official, slick implementation, without having to think about adding mods is always better. I'm on the edge of writing my own interpretation of Arsenal, if anything then out of spite for those issues. However, this recent change gives me hope that we'll see significant revisions to Arsenal.