rübe

bwahaha, haven't noticed the necrobump. :rolleyes:

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.

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? -_-

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)

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)

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.

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)

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

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

Implement some state of the art text-to-speech (TTS) solution. Screw voice acting, and train a bunch of models instead. Profit! B)

And why is that? Did this boil down to some specific aspect/side-effect of fatigue? Or was disabling fatigue just the simplest way to get to a "polished" product for the contest (...who knows, maybe because fatigue came a bit late to the party, and mission designers had not adapted yet?)? Did this depend on the category (sp vs. mp), or maybe some other criterium (pve vs. pvp)? Either way, I don't think that it's fair to look at fatigue from this point of view. It was a contest. Fatigue was (and obviously still is) a new thing. And AI looks rather stupid now, because they (still) have no concept of fatigue - certainly not on a group level. So... just how crucial was AI, or the unwillingness to fix the AI (w.r.t. fatigue), here? I'd argue good defaults are more important than the option to screw things up as one pleases.

:mellow: Honestly? That's the reason? People are confused (by a simple concept like fatigue - in a game like Arma...)? Industry standard? Fundamental at that too? ...I mean, you are aware that "popular" gamemodes like BR or KOTH easily can and do disable (or modify) fatigue - just for the plebs, right? Why can't I stop thinking you guys just aren't up to fix the AI w.r.t. fatigue (or non-linear speed/movement capabilities), s.t. they would handle it in a reasonable way (...instead of constantly being fatigued and unable to keep formation and generally breaking all scenarios designed before its introduction)? Yeah, I don't buy it. -_-

What functions do you use?BIS_fnc_dirTo BIS_fnc_relPos BIS_fnc_rotateVector2D BIS_fnc_setPitchBank BIS_fnc_arrayPop BIS_fnc_parseNumber BIS_fnc_classMagazine BIS_fnc_classWeapon What functions need improvement?- What functions would benefit from dedicated scripting command?BIS_fnc_dirTo BIS_fnc_relPos BIS_fnc_setPitchBank BIS_fnc_rotateVector2D BIS_fnc_arrayPop BIS_fnc_parseNumber That's pretty much what I currently use (did a quick search with grep). Personally I make excessive use of dirTo, relPos and arrayPop (we got pushBack already, so an atomic pop might be nice to have too). So if these three guys could be (a bit faster) commands, I'd take it. ;)

The best thing is to write a script that extracts/lists the classes (and attributes) you're interested in directly from the config - which includes 3rd party addons and everything currently loaded. BIS introduced some new config commands/functions lately, which should come in handy. The second best - and probably easiest - thing is to use the ingame config browser, although I whish this thing would be a little, lightweight standalone editor like application, instead of being embedded in the game itself, which frankly, is not very useful (you can't keep it open while working with the editor, it's super slow to load or switch branches, ..., super annyoing in general. Same applies to the function browser.)

In the end this is a question of scenario/mission design. Maybe don't give a faction all that armor, if the other is equipped with 5.56mm guns for the most part. Or find other aspects to balance things out. Take KOTH for example. It's not Arma's fault that every one (and their mom) runs around with a Navid/SPMG. It's just that the mission is badly designed. Instead of accumulating individual work towards "the best" equipment (which sticks permanently w/o additional costs... go figure), maybe that progression should be kept to the spawn of a single round of KOTH, where you each time start anew with cheap equippement, but can earn/unlock better stuff as the (single) game/round progresses... or what not. Many interesting mechanics can be thought of to come up with better balance and a more dynamic mission. E.g. why not give better toys to the side(s) currently losing?

See: https://www.reddit.com/r/arma/comments/3mzbr8/after_dev_build_update_cant_load_my_mission_in/ ...guess a reasonable strategy might be to save a very simple mission now (i.e. something you can recreate in about 2 seconds), s.t. you will be able to easily look at a diff, to see what essentially has changed.

Yep, somehow I just don't see how this is a problem though. So we can't (or shouldn't) refer to map/world objects by id. But hey, that's fine. Nobody cares about those ids anyways; it's an implementation detail better left hidden (because it can change). This, frankly, is no new problem and it's easily solved by proxying such objects. Thus, what we need are proxy map/world objects, that do the nearestObject stuff internally and which would translate to some (hidden) init-script burried in the sqm file (or what not...). Simply make such a proxy object snap to the nearest world object it can find by default, and maybe give us an option the further restrict/define the classes to look for. Id's can change, nobody will care or even notice. Problem solved, no need to change the implementation of the terrain or what not. B) Yeah, too bad not all objects have proper classes defined. But even here a proxy might just work fine. It's not that nearestObject doesn't find such objects. It's just that typeOf _x returns an empty string. However, format["%1", _x] gives us the filename of the object, with which you can classify stuff (either by direct mapping, or regex, or what not...). Moreover it might not even be necessary to know anything about the class of a map/world object. Just have the proxy snap to the nearest object it finds, and be done with it. Sure, this would probably restrict options we could do to such an object (e.g. for lights we should be able to turn em on or off, for gates/door we might want to open/close them, for buildings there should be a streamlined option to pick from interior compositions, ...); yet we might still be able to at least damage/destroy it, no? :ph34r: EDIT: And if you save the object behind such a proxy (or rather a hash of it) too, then you can savely warn the user in case the proxy should find a different object - all of a sudden (due to map changes or what not...).

Hm, wild guess: maybe the installer needs admin rights (I've turned off UAC a long time ago, because screw it, that's why... :lol:)? <_<

Yup, exactly what's needed for building interior compositions (or what I've called anchored [to the building] compositions above). And with modelToWorld this is actually no big deal at all (well, I hope we do not need to rely on disableSimulation, attachTo and other stupid tricks to keep things in place - and out of the loop). All in all we'll need: free compositions (as current compositions) that only have a relative position to each other. fixed/absolute compositions (e.g. to import stuff that has been placed down on the same map) relative/anchored compositions (e.g. to a building) I'm pretty sure we'll be able to make good use of "custom tools" for such tasks. With all3DENEntities this should be a clean and easy task. We'll just have to hope the Bohemians give us the means to write to files (say, other than the rpt-file, because that sucks). I mean... just in case there won't be anything official (or it doesn't meet our standards, bwahaha). :lol:

Worked fine over here. Are you sure you've got the thing with that "steam guard code" right? I left that field empty (as suggested in case you don't know any better...), but once a console came up I was prompted to enter one... but fear not, steam should send you one by email at this point. Other than that, I have no idea what could have gone wrong. :huh:

:blink: Yay. Thanks buddy! :lol:

Changing from stable to devel branch (and back...) is currently quite a pain - is there really no way to have both branches installed in parallel with steam or something? -_-

Yeah, this. A much more general solution than being able to just merge two missions. Now you should just be able to save one mission as composition and load it anywhere else (maybe there should be an option to load a composition with fixed/absolute coord.-sys./positions). Eitherway, I hope it also will be super easy to share new compositions (e.g. to post/collect them here on the forums). Actually it might be worth a shot and see if it'd be feasible to fully integrate this sharing of compositions (browser/updload/download) with steam workshop or something. Oh, and: remember the discussion about closed buildings vs. open yet empty buildings? With a 3d editor in the hands of the users, that discussion is over. There. I said it. :lol: Empty buildings are just perfect. What's missing is a streamlined way to decorate/populate them. What we thus need is an easily extendable library of interior compositions on the one hand, and on the other hand an easily configurable framework to spawn, keeping some kind of state, and despawn such compositions during a mission. And we get customized and super detailed building interiors (possibly with units and some waypoints/scripts and stuff), while (hopefully) still going easy enough on the CPU.

...wait, what? :huh: :mellow: One would have assumed that especially this, interaction with map objects, would be finally easier and more comprehensive... I mean, with a 3d editor, you might as well have a dummy simulation thing going, and everything you do gets 1) executed and 2) put into some autogenerated (and hidden; burried in the sqm file) init-script that will be executed before the mission starts. Linking/syncing map objects? Pfff, that should be super easy. What about: destroying map/world objects like houses, streetlamps, or vegetation? (we still can't delete stuff, without having to reload the map afterwards, hu?) selecting a building, and choose from a suitable interior-composition. Simple stuff. :) maybe not related to map objects, but putting units into certain animations should be easy now; guess that too requires some kind of simulation, no? and what not... I mean... come on. :rolleyes: Maybe some dev might wanna clarify what will be possible/what's planned for, or something?

What exactly is "Tools > Community Tools..." about? Does it already work? And if so, how? And will be be able to write to files other than the rpt file - e.g. to write some custom exporter? B)