Sniperwolf572
-
Content Count
3304 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by Sniperwolf572
-
3DEN usability tweaks suggestions/discussion
Sniperwolf572 replied to Sniperwolf572's topic in ARMA 3 - EDEN EDITOR
Any info in regards to the #1 item in the list? It seems like it didn't make it to the stable release of Eden. :( -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
I see. I understand that the reload mechanic isn't the same between man and vehicle internally. However, in game, both reloads are presented as following phases: 1. You hit reload 2. You are unable to fire for a certain time while the action is performed 3. Reload is complete and you can fire Sometimes you want to do things as the reload is starting, other times you want to do it as it has ended. How the engine deals with it internally at times is not helpful when you need to do things visually. For example, you might want to eject a shell casing after the reload has been completed. Currently, you'd have to read reload length for the mag and manually delay whatever you want to do. However, for the soldiers, you might want to things before. And so on. Still, if we're at the awesome point where the reload EH is finally being implemented, there are various reasons (some listed above) to have predictable EH's and split into pre and post variants. Additionally, the term "reloaded" in it's tense, suggests that it's going to happen after the action has completed, but that's just semantics. As I said earlier, if it's possible to implement a pre and post reload EH's as "ReloadStart" and "ReloadEnd" and to keep the behavior consistent between vehicles, it would be awesome. If not, it might be worthwhile to separate them into something like "ReloadVehicleStart", "ReloadVehicleEnd". "ReloadManStart" and "ReloadManEnd". I'm pretty sure implementing pre and post reloading EH's as such would not cost anything meaningful, but we would gain flexibility and less need to deal with other case. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
New commands and new event handlers probably. I suppose whatever they use to track ammo low/out of ammo flags for the AI and UI. Ammo being used up needs a wide coverage, not just when fired. Ammo removal from the inventory, etc. I'm just saying that the game firing a reload EH when a unit is out of ammo in inventory due to firing a weapon would be inappropriate for what the EH is supposed and expected to do. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
I wouldn't use reloaded for that, seems out of scope for reloaded. As for the begin and end reload stuff. The tense used in the name of the event handler suggests that the man implementation is correct and the vehicle implementation incorrect. As a suggestion, before this hits stable, it might be wise to split it into ReloadStart and ReloadEnd as I'm sure there are various cases where you'd use one or both. For example, ReloadStart to do fire stuff like bolting anims and ReloadEnd to manipulate the mag state post reload. -
New EDEN update makes font look disgusting...
Sniperwolf572 replied to AzZaMaTr0n's topic in ARMA 3 - DEVELOPMENT BRANCH
I'll bite and "rage some more". I've seen the first iteration of the ingame kerning of Roboto, I agree, it was much worse. As for the picture, surely you can see what I'm talking about? Kerning of the in-game one looks much worse than the original one, the font lost it's "crispness" and became somewhat blurry, even the individual glyphs lost their shape. "S" got a tail, back of the "c" is no longer flat, back of the "e" is no longer flat, "n" got squished, "r" lost the dip at the connecting point, "o" somehow became rounder, etc. The overlay, it's not representative of the difference, as it's approximately the same as having a 10cm white circle covered by a 20cm red circle and saying they're the same because no white can be seen. Besides, at that size, single pixel can change appearance and readability of a character drastically. And I suppose, yes, we can skip the discussion about design decisions in regards to using the condensed light font. As far as the comments at the old font go in regards to a few characters being quite similar. I'll agree that was the case, but tweaking a few font glyphs would've made much more sense. Anyway, thanks for your time. -
New EDEN update makes font look disgusting...
Sniperwolf572 replied to AzZaMaTr0n's topic in ARMA 3 - DEVELOPMENT BRANCH
I find the problem to be three things, one which is technical and two design decisions. The technical issue is the bad kerning which causes awkward spacing between letters. For example the word "Scenario" looks like "Scen ario" in the Eden editor menu and dropdown due to this problem. The above issue combined with the condensed nature of the font and the general "lighter" appearance of the font make words harder to distinguish and any slightly longer text harder to read. I understand that the condensed version gives you more room to fit more text in smaller areas and avoids having to tweak the UI itself, but, eh, I'm just another person "raging about the new font". -
New EDEN update makes font look disgusting...
Sniperwolf572 replied to AzZaMaTr0n's topic in ARMA 3 - DEVELOPMENT BRANCH
I'm flattered. -
New EDEN update makes font look disgusting...
Sniperwolf572 replied to AzZaMaTr0n's topic in ARMA 3 - DEVELOPMENT BRANCH
No it's not. Inventory menus, action menus, ammo counts and various text controls, and so on. The new font renders horribly ingame. Roboto is a beautiful font, but the game font rendering mangles it so bad. The engine is incapable of rendering the font crisply, not even the straight lines, and you end up with a letter "I" that has blurry edges. In comparison, if you go to the Arma 3 website and read some stuff there, like the SITREPs, the font is nice and beautiful as it's supposed to be, because it's rendered by your browser, which is capable of not rendering it like a piece of shit. As a person who's been working with UI for 6 years, I'd have no problems with changing the font, I have problems with horribly rendered text. It's not about getting used to it, it's about difficulty reading it. This is the first time in my 14 year history of playing Arma games, that the ingame text is giving me headaches. -
Oh snap it's proof of concept time again with guerrilla scripts and slightly evil code! This time it's the fluid door opening thing that was inspired by what we recently saw in .You can find the source code on GitHub. Code reviews are always welcome. What is it? This addon enables you to hold a key, then roll your mouse wheel to incrementally open doors and hatches. What key do I hold? By default, the hold key is TAB, but you can change it to anything you fancy through CBA's keybind menu. Just hit ESC then go Configure > Controls > Configure Addons. Here, select "TEN Fluid Door Opening" from the "ADDONS" dropdown menu and change the "Fluid Door Opening (Hold + Mouse Wheel)" to anything that you find comfortable. Please do try to avoid key conflicts. My action menu and crosshair disappear while I hold the "Fluid Door Opening" button! This is intended. It prevents the mouse wheel from scrolling the action menu while you are opening doors. Sadly the crosshair is bundled in the same subset of the command that the action menu is. The doors are no longer animate silky smooth! As BI added door animation sounds, there is no longer a way to play animations without sound, unless you do it with the instant param. I chose to go with no sounds, but rougher animation so you can be at least slightly sneaky. I'm on Dev branch, the doors open, but I can't pass through them!? Yeaaaaaaaaaaah. Ticket for your voting pleasure here. If this ends up on stable, we'll have to go back to squeaking doors. Dependencies? @CBA_A3 - Keybind handling, until BI comes up with a better solution SHOW ME! Changelog: Download (version 1.1.0): Dropbox Steam Workshop
-
I just meant that I wouldn't consider them "new" or "oh these things suddenly appeared recently". :p
-
I don't think it is, I work with Roboto quite a lot and certain glyphs are different. Doesn't seem to be that either, unless they mixmatched certain glyphs from other fonts. Both are referenced in the config viewer, Roboto as a new font, and Noto Sans in Etelka properties, but I refuse to believe those two fonts can be rendered so ugly. :P
-
Can't say I'm liking the new font. Old one had a few horrible glyphs, but the game rendered it crisply. This one seems inconsistent, badly aliased and difficult to read overall unless there is some extreme contrast. I'm not sure if it's the game font rendering that makes it horrible or the font itself being that way. It feels like a condensed light version of whatever it is, which would suggest it was picked for space reasons. I'll also agree with the people who said that it also kills the identity of the game. Do we know which font is this?
-
Most, if not all of those have been there for at least 3 months.
-
I'm not sure if I really need to point this out, but your link points to the Arma 3 Digital Deluxe edition + all the DLC + apex preorder and not just Apex.
-
BETA to STABLE mission releases (not current 1.54x)
Sniperwolf572 replied to jcae2798's topic in ARMA 3 - EDEN EDITOR
They probably will work, but I'm sure nobody will guarantee you that they will. Eden is still in development and the file structure might change to adapt to improvements. If I remember correctly, that is what was said when Eden got pushed to the dev branch. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
I agree that the apply does seem to suggest and would probably make sense to have the modify behavior, but I don't believe arrayIntersect behavior should be considered weird or incorrect in creating copies. You're operating on two arrays and I believe it would be highly unexpected, cases like this would be very weird and additionally you'd have to make copies manually to avoid this behavior. private _group1Bros = units group _broGroup1; private _vehicleOccupants = crew _theVehicle; private _groupBrosInTheVehicle = _group1Bros arrayIntersect _vehicleOccupants; ... _group1Bros setDamage 0; -
It's not damage control, the symptoms were very obvious, it's what they say it is.
-
Sneak peek at the new shaders: Source: https://twitter.com/maruksp/status/677891075487453184
-
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
While I'm at it, would it also be possible to expand the createRope command, to accept custom segment objects? Would be nice if we could create different looking ropes than the bland default ones. :D- 1481 replies
-
- 3
-
-
- branch
- development
- (and 2 more)
-
I think it's mostly there for the bullet impact effects.
-
Pretty sure they are, here's an excerpt from an article I read a few days ago on the Biki. Depending on how the fire geo for that bush is constructed, even if in the material the fire geo blocks allow for full penetration, a unit inside a block of fire geo will not get damaged if the bullet doesn't actually pass through it. A simple test would be to make a visually transparent cube, with an empty geometry, a fire geometry with the same size as the visual geometry and apply the same material like the bushes.
-
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
Would it be possible to add a hit command, or an param/tweak to one of the setHitX commands that allows us to damage things like helicopter rotors to the point where they actually disappear? I can get the desired result to happen by simply flying into a pole with a helicopter rotor, and it visually goes away, but with a script, no matter how much I damage one, at worst they just change to the damaged texture. My memory seems to recall that when I used setHitPointDamage in the past, this used to happen, but I am not 100% sure this truly was the case. -
Come to think of it, the first (or was it second?) mission of the Bootcamp campaign where Adams explains to the AAF, so smugly, how the old fatigue works is now absolutely pointless and teaches absolutely nothing. Poor guy. :D
-
Fatigue Feedback (dev branch)
Sniperwolf572 replied to solzenicyn's topic in ARMA 3 - DEVELOPMENT BRANCH
I really don't see how the logical step there is to gut the generally favored fatigue system and not improve the generally disliked medical one.- 1930 replies
-
- 1
-
-
- branch
- development
- (and 2 more)
-
Fatigue Feedback (dev branch)
Sniperwolf572 replied to solzenicyn's topic in ARMA 3 - DEVELOPMENT BRANCH
As horrible as the stamina system itself is, stamina bar does not in any way deserve to be on the wall of shame. It's a segmented bar with two icons, if that is confusing, then I don't know what isn't. Shove it away through the UI editor and you don't have to look at it. If you want examples of the "UI elements that indicate you're in a vehicle or that you're holding a weapon", guess what, they're right there in top left and top right and were since OFP. Please, don't advocate for more things to be indicated by more heavy breathing, wheezing and sighing, we shouldn't be deducing the stamina state by the pitch shift level of the heavy breathing the character produces. UI items for intrinsic things to a human which can't be conveyed in the same way through the screen is perfectly fine. Guessing between injuries, hold breath feature and stamina solely by heavy breathing sounds is a much worse alternative.- 1930 replies
-
- 1
-
-
- branch
- development
- (and 2 more)