Jump to content

rübe

Member
  • Content count

    1049
  • Joined

  • Last visited

  • Medals

Community Reputation

97 Excellent

5 Followers

About rübe

  • Rank
    Master Gunnery Sergeant

Contact Methods

  • Website URL
    http://non.sense.ch/

Profile Information

  • Gender
    Male
  1. Weird contact spotting...

    See: https://community.bistudio.com/wiki/knowsAbout (and maybe: https://community.bistudio.com/wiki/targetKnowledge). Units of the same side (i.e. allies), but not in the same group, still nead to "learn" about each other. The side of a newly spotted object starts with side "unknown", hence the unknown contact, which might be friend or foo at this point.
  2. Not exactly, but you can just do a switch(true) and have your cases evaluate to boolean, which should be nice enough anyways: switch (true) do { case ((_var select 0) isEqualTo "String"): { if ((_var select 1) isEqualTo 123) then { diag_log text "match both"; } else { diag_log text "match string"; }; }; case ((_var select 1) isEqualTo 123): { diag_log text "match number"; }; default { diag_log text "no match"; }; };
  3. @Dedmen I see, backwards compatibility is the actual problem here. Yeah, that's always nasty, and now is certainly not the time to do anything about this.
  4. @.kju sounds like fun times.
  5. @Tankbuster yep. unironically. If you're going to streamline array syntax, give us the usual C syntax already. array[i] Anyone is comfortable with this (and don't tell me the parser couldn't be improved to handle this, it's really no big deal). But this cryptic hashtag? Just because it's shorter than writing select? No, thanks.
  6. So... what's the point?
  7. very nice. Yet I wonder if that mini-game isn't misplaced. Once you're logged in, managing the generators should be straightforward. If you insist on having a mini-game, why not have it for hacking the thing?
  8. Even with doMove (or moveTo down on fsm level), making the AI run as long as known threats are around is a hard one. You'll probably have to experiment with disableAI (e.g. targeting) in an attempt to make them ignore enemies and concentrate on running, and even then... (maybe continously reseting/earsing knownTargets helps, since that's an option now?) I'm not sure if people ever managed to do this properly/in a satisfactory way.
  9. Could someone please either confirm, or deny that the following is still a problem on the devel branch? https://feedback.bistudio.com/T128002 1) doStop all units (with scripting) 2) try to make them follow you again with direct commanding (radio 1-1) Does it work/do AI units follow you again? For if not, this kind of AI direct command deadlocking seems to be pretty game breaking to me.
  10. oh... of course, it's Arma afterall. You do what you gotta do... sure, sure.
  11. Sure. For one duplication: if you actually go on and do translate your strings to multiple languages, you're going to duplicate all your styling, which is a mess to manage. And for two, flexibility: you might wanna use the very same string in a different context, maybe with, maybe without, or different styling alltogether. In the end, styling can be considered "code" and doesn't need to be translated. It's not "language" (or "data").
  12. Might just be me, but I don't think you really should put style into a stringtable. Just pure strings. Then apply the styling (an extra call to format, or simple string concatenation/appending) just before you call createDiaryRecord (or whatever).
  13. From what I understand: no, not really. The models are all fine. It's just that certain LODs (memory lod I think?) should not be considered while computing the bounds. But of course, that might only be half of the truth (maybe stuff has all to be rebacked/repbo'd or what not), I don't know... all I saw was just another opportunity to mention the bb-problem again (while pulling of a shitty box in, wait no, outside the box joke at the same time, I'm deeply sorry for that ). This is true, and most likely the reasonable thing to do. But is it really the same? Semantically? I'd argue no, and the difference might be significant. Locking to a well (or explicitly) defined position in a model assumes some prior knowledge of the target vehicle, while the center of a bounding box is an implicit definition: something that can be easily observed without prior knowledge (e.g. by the targeting mechanic). And secondly the bounding box center (if computed correctly) might be the more robust target, for maybe that "aimpos" isn't well configured on all(!) models, or [0,0,0] might be way of in another. But I don't really know, so I'll better shut up now.
  14. it sure does, but shhhhh... Let's think a bit outside the box for a second here: how about the bounding box (i.e. boundingBoxReal) gets finally fixed after all these years? How about that? Too radical?
  15. Broken shuffle reported in 2016. No big deal. Still not fixed in 2018... I'm not exactly sure why at least the simple stuff can't get fixed in a timely manner, but something (organisation? processes? ...) is just broken/not functional over at BIS. Isn't it?
×