Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

Community Reputation

52 Excellent


About rübe

  • Rank
    First Sergeant

Contact Methods

  • Website URL

Profile Information

  • Gender
  1. 1.54 Fatigue is too Unrealistic

    Current weapon sway might even be "realistic" (in terms of distance travelled, not so much the pattern maybe), but that still wouldn't mean that it's appropriately modelled. The extend of sway might be spot on and still translate horribly to the game. Your brain can do amazing things to stabilize your view(!) in real life. I don't think this really works the same while looking at a computer screen. And having an input device without immediate physical feedback (keyboard/mouse) doesn't help either. Hence a proper *model* needs to account for such things.
  2. Open Letter to Bohemia: We can help

    For starters, that's not how things work: Don't call us, we'll call you. B) So..., you can't be bothered to give feedback on the dev branch, and also the feedback tracker isn't good enough for you. Instead BIS should go after their "followers" (which don't seem to follow them too well on the dedicated communication channels), guess a private séparée would be nice, because you recognize that they can only do so much at a time? Yep, just let's throw some "more teams" and "more input" at them. That will do. <_< Don't get me wrong; your heart might be in the right place, but I highly doubt BIS has waited for your slightly naive proposal.
  3. Fatigue Feedback (dev branch)

    I don't know, but this all smells a lot like design by commitee. Who is the guy in charge of this? I'm not looking for a scapegoat, mind you, but for someone with a clear vision and a sound plan w.r.t implementation too? Chances are there is no such leader. Hence the foul compromise. :ph34r: And yes, fatigue wasn't broken by itself. But as a side-effect AI was, since it never did get adapted to cope with fatigue at all (...and again: who is the guy with an overview over all parts that should merge to one lovely game? Surely this problem must have been obvious from day one fatigue has been envisioned? What was the plan there anyways, e.g. w.r.t. the campaign missions, default loadouts, etc.?). Anyways..., fatigue got implemented, the obvious problems came up as expected, but instead of fixing the AI, BIS rather choose to dumb down fatigue - which just got implemented - call it stamina, and then a day... And instead of affecting the movement, we end up with that silly sway-minigame, because that's no problem for AI, but still some kind of punishment annoyance for the player... Fatigue should be *all* about movement(-restrictions). That's what complements all the different "gears" and weapon lowering and stuff together with the new inventory of A3. And that fatigue-/loadout-/movement-/risk-management is was a very interesting, fun and rewarding "mini-game" - be it in the offensive or defensive - with direct/immediate feedback (that IMHO doesn't even need some stupid indicator widget thingy) and consequences. With no fatigue but stamina we're basically back to an infantry-vehicle with a single, steady gear. Happy jogging, all day long... and have fun with that super annoying weapon-sway. Fatigue, together with all the different stances/modes of movement, was on track to be something really great for an infantry-centric game. That's why the current stamina-crap is such a damn shame (...besides the wasted development time for fatigue, and then stamina, ugh... again, who is managing this kind of process?!). :(
  4. 1.54 Fatigue is too Unrealistic

    Uhm... Yep. Pretty sure about that. :mellow: Ohhh. So AI actually was a factor in the decision to butcher fatigue afterall? Interesting... You see, what pisses me of the most here is the communication from your side. Remember that post from royalityinexile? It didn't make any sense then. And it doesn't make any sense now. And from there on there was barely any worthwile (and visible) interaction to discuss or at least clarify things. Well, it's your game, so do whatever you want. :P ...I'd just prefer silence over some bullshit excuses, empty marketing babble and a good ol' smoke screen. :unsure:
  5. That's nice. :lol: However, I'd really prefer to use mean and variance instead of min, mid, max. Any chance this could be implemented as well? random x: uniform distribution random [mu,variance]: gauss random [min, mid, max]: non-symmetric gauss? How is this even implemented? Like a piecewise function that isn't really C2 continuous at mid? :wacko: Edit: okay, either I'm too dense, or the given examples might need some more explanation. random [0,5,10]: okay, I guess I can imagine what's happening here. Mean at 5, with a variance of ~5/4. random [0,10,0]: so now max < mid. What does this mean? Is max simply irrelevant here? Or is the actual max mid+max or something? From the given data, mean is simply at 10 now, but what about the variance? random [0,10,5]: uhm... okay what now? Variance got smaller (with a larger max.)?! I don't get it. :( Double edit: oh... so that just flips/mirrors back around the mean? I.e. random[0,10,0] is actually the left side of mu=10, variance=5/4... just with twice the amplitude? And random[0,10,5] works similar, just that the flipped right side is now also skewed (or has a different variance) before it merges/overlaps with the righthand side? Okay, that makes kind of sense, I guess...
  6. bwahaha, haven't noticed the necrobump. :rolleyes:
  7. Given your input (_array1) is already sorted (no matter if ascending or descending; doesn't matter), you can do something like this to filter values that are sitting to close to each other: _array1 = [24.37,24.38,24.40,42.44,42.45,87.21,87.22]; _threshold = 0.5; _filtered = []; _last = -1; { if (_forEachIndex == 0) then { _filtered pushBack _x; _last = _x; } else { _diff = abs (_x - _last); if (_diff >= _threshold) then { _filtered pushBack _x; _last = _x; } } } forEach _array1; // use/return _filtered This is absolutely untested B) , but you get the idea. Have some threshold and keep track of the last value you've pushed back, then you can simply compute the difference between the next potential value and the last one pushed back and see if it's larger than the defined threshold.
  8. Well, anything else simply sucks. :ph34r: Okay, so a bottom-up approach is rather difficult, how about a top-down approach instead? For each faction you first read out a mapping of soldier roles (e.g. rifelman, machine gunner, sniper dude, ..., you probably also would want to consider CfgVehicleClasses to get at special teams such as divers, recon, ..., for extra pricy stuff). Then you have a look a their equippment (now you know: "aha, this is a sniper rifle!", "this one a marksmen thingy", etc.) and classify/price stuff accordingly. Granted, this only works if factions are properly and fully/extensively configured. And clearly you might miss certain weapons alltogether this way (no luck with mere weapon packs). But on the bright side this could allow for a good balance in pricing (e.g. across factions) due to the high-level of abstraction here (infering weapon types based on soldier roles). Oh well, just some food for thought... ...have you seen this thread over here already? -_-
  9. Fatigue Feedback (dev branch)

    Yeah, fatigue is definitely on the simulation side of things - a thing that shouldn't depend on game mode (and even difficulty settings are questionable in this regard). I'm not saying that such things shouldn't ever be tweaked, but the proper place is rather a (total conversion) mod. The Arma gameworld/simulation should be consistent across game modes. Also: why not tackle the problem from the other side? If we could simply "model away" fatigue/stamina by giving units uber-human endurance-skills, you could easily have your cake and eat it too. This might be semantics, but technically the fatigue simulation wouldn't be touched at all this way, just the unit. Such endurance-skill bonuses could also be easily attached to some inventory-objects (e.g. uniform/exoskelet stuff), and again, no need to mess with the fatigue simulation at all. Messing with the skill-set seems to be way more transparent (granted, you don't get to "see" your skills ingame) and high-level/missionmaker-friendly, and also much more flexible, given it can be based on individual units. Currently BIS tries to only offer "reasonable" settings on a range from 0.0 to 1.0. Maybe that should change, s.t. much more extreme skills could be effectively achieved. tl;dr: people shouldn't (have to) mess with the fatigue simulation at all. Just tweak the skill-set (e.g. endurance) of individual units, and be done with it. B)
  10. work out size of town

    I think you can now get rid of BRfn_inString and simply use the find command instead (which can find (sub-)strings in strings since A3 or something...), which should speed things up a notch already. And maybe you could get rid of those _points = _points + [...]; constructs (or _a set [(count _a), ...] for that matter) and use pushBack instead (hm, a pushBackAll might be handy...), which again should be slightly faster, since the + operator constructs new arrays (though that got optimised at some point in A3 I think (see: Array: Adding (appending) to arrays)..., so not really sure what's happening nowadays.). As for the computation of the polygon centroid... I'm not sure why the algorithm would fail in some cases, but I doubt that it's about the size (as in area?) of the polygon. Maybe there is some bug that messes up the sequence/order of the points of a polygon, or...? Hm... Either way, sorry about that. :P Anyways; cool beans! B)
  11. work out size of town

    You can immediately tell this is all wrong by looking at Kylania's small screenshot. :o Once upon a time, at least official maps had proper configs... :( Anyways, here's a suggestion for some quickfix: Take the max (or min) of RadiusA and RadiusB, s.t. you end up with circles. Weight/scale the radius by a factor depending on the location type (CityCapital, City, Village, Local, ...). Or, alternatively scratch the original RadiusA/B alltogether, and just fix radius depending on location type. ...assuming at least the positions of the locations are fine.
  12. Fatigue Feedback (dev branch)

    I'd argue movement - and thereby the position you're shooting from - is way more important than shooting in a "tactical" first person shooter. And this becomes painfully obvious playing in a team/with a group. Or better yet: against them! :o With all due respect: there is no such thing as a "tactical shooting part" (okay, maybe suppressive fire, but that's it...). Tactical stuff is all about movement and your (relative) position (flanking, covering sectors, cross fire, ...). Shooting is the easy part. Nice video. :) But hey, why not give the full quote: Amen. B)
  13. Oculus support

    Re: Oculus Dk2 Arma 3 VR HOLY SHIT this is wild, watch for a bit from 7:50 on... What the hell?! :lol:
  14. Fatigue Feedback (dev branch)

    Right? There has to be some other reason that hasn't been mentioned yet. Why else would you scratch fatigue, an overall lovely system, completely? It just doesn't add up, especially if you also consider the (limited) resources BIS is willing/able to put into A3. This decision is simply not comprehensible. And hence I'm not only upset about the introduction of stamina in favour of fatigue, I'm also slightly worried about the communication from BIS in this regard. RiE reiterating those (original) five design goals doesn't help at all. Fatigue was (almost) there. Stamina is not even close. Yet, I don't think this comes really down to actively dumbing down things for the masses (the interface might be a better place to start here...). Instead I still suspect the AI is more of a problem here than actual people. Unfortunatly BIS doesn't seem to be willing to put too much effort into AI (MP sells copies of the game, SP probably not so much...), fatigue screwed them over, so better put in something more AI-friendly... No fatigue for jogging while not respecting the actual loadout or terrain or anything...? So AI can easily move from A to B as a group, despite different loadouts/capabilities? Perfect! ...can't really think of anything else that would lead to this decision. <_< :mellow: If you do this with your AI squad you will have all guys shouting "out of ammo" at you. :lol: I know, because I made them do this, while waiting for the rest of the team in case of fatigue/out of formation... At least AI has no problem locating/picking up their backpack once all guys are rested good enough again. :P
  15. Implement some state of the art text-to-speech (TTS) solution. Screw voice acting, and train a bunch of models instead. Profit! B)