rübe

A (small) random component is certainly needed, otherwise a crew with same settings still act all the same/like robots. Still, the main components should be: 1) latent skills (e.g. spotDistance), and 2) current conditions (e.g. fatigue or morale). On a side note: does fatigue influence other skills? E.g. does spotting distance get worse with increasing fatigue? That'd be kind of cool, no? Anyways... And then there's always the question of modelling various forms of communication/communication channels (e.g. radio). How long does it take for unit A to alert his leader (unit B) somewhere else, who in turn might alert officer (unit C). And can you kill unit A before that chain is set off? And can we model the classic inversed pyramid of information in (mil.) communications? E.g. the most important thing first (we're being fucking attacked), giving more and more information/detail with more time/later (who/what is attacking? where is the attack? from what direction? casualties? etc.). The result being: the longer unit A can report about some incident, the more precise the knowledge for his peers will be (e.g. knowsAbout). The problem here is that parts of this is hidden in the depths of the arma engine we can not influence, while the remainder can be easily scripted on top of it; but should we really have to, or wouldn't a native, maybe parametrized solution (maybe with triggers/some hook methods) be more appropriate?

Agreed. The level of abstraction was fine for OFP, but now with Arma 3 it's just way too high. Actual units should have to perform actual work (some nice animations with some predefined repair-positions per vehicle or something, or just some position based on the bounding box as a fallback... and maybe even some walking around, dragging/moving parts from here to there) in order to repair a vehicle. And similarly, actual units (or machines/some process) should have to do some job to refill fuel/ammunition (or for vehicle customization). The important factors here are: clear visibility of what's going on (actions, animations), time (not so much resource!) consumption in a state unable to fight/handle weaponry, and hence the opportunity to (forcefully) interrupt that process. It's a difficult thing to decide what should be modelled and on what level, especially on the logistics side of things. But abstracting physical work completely away, turning it into a magical one-click action... that just cuts out far too much fun and interesting gameplay opportunity.

It probably all boils down to AI, which they couldn't get to work as they envisioned as they showed us those sneaky stealth mission stuff way back then... so the feature got cancelled to not have to officially support and hack around this forever... Giving scripters the forceAddUniform command officially means: sure go ahead, but you're on your own now buddy. Good luck coming up with something where enemies react "reasonably" to your oh so clever disguise. And to be honest, that was probably the best decision here. There are far more important things to tweak and improve, than such very exotic and highly complex features (that make for a good youtube showcase, but aren't really that important afterall, and would break half of the time anyways... a uniform is just a tiny part of a persons/soldiers identity afterall).

@By-Jokese Also make sure to check out the BIS function library which contains a bunch of handy functions for geometry (dirTo, relPos, ...) and vector maths (vectorMultiply, vectorAdd, crossProduct, dotProduct, rotateVector2D, ...).

@By-Jokese Check out: https://community.bistudio.com/wiki/modelToWorld and then a position a meter in front of the player just boils down to: _pos = player modelToWorld [0,1,0];

you have to untoggle snap to surface and maybe that other toggle (right next to it) too...

Actually, there is a way to do it nonetheless: https://community.bistudio.com/wiki/forceAddUniform ...although it's not a very nice thing to do for respectful soldier.

Btw. the Enfusion engine will allow for "terraforming", s.t. we could just (smoothly) level a certain spot if we'd like to, right? Right?? IS THAT A YES???

Is there any way to get a sub-terrain view? That is, I need my camera below ground-level, and I also need to have a (semi-)transparent ground to see what's going on beneath there. If not, please consider this a feature request. Use case: building compositions that all align (modelToWorld) to a central piece, typically a house. A3 structures tend to have quite some more object below ground level, be it for extended legs (towers, container buildings, ...), or outright fake terrain (e.g. old A2 warefare buildings). As long as I place objects of the composition inside, or ontop of the building, everything works out just nicely, but once you start to put pieces down right next to the building (e.g. sandbags) you'll quickly run into problems, as soon as you spawn your composition somewhere where the terrain gradient is too high: your sandbags are flying in air, while the house/building itself can count on its sub-terrain features. The solution is straight forward: also have sub-terrain features for a meter or two, maybe more. It doesn't always work for everything, but for walls or sandbags this works just fine: stack them, maybe two or three pieces on top of each other, then put all but the top-most one below ground level. This works pretty good, but only if you plan ahead. Once you've moved your sub-terrain features below ground-level, you can't really edit stuff any longer. You're blind. And in the worst case you have to start all over... You get the idea, or here, just take a look (notice the sandbags on ground-level; stack of 2 on top, another 2 below ground): Now observe how the third stack (or first row below ground) becomes visible once put down somewhere on stratis. Weren't it for these sub-terrain features, sandbags would be flying now:

If only the SQF parser could raise an error already upon trying to derefer an unknown literal/variable (typically due to some typo) instead of just going silent and answering with nil... that'd be soooo great. Seriously... who is responsible for this? Who did this and thought this was a reasonable decision? YOU OWE ME A BEER OR SOMETHING!!!!

Yep, disabling pathing keeps em nicely in place, but they rotate and engage just fine. While doStop keeps them in place only for as long as combatMode (I think) doesn't raise to yellow or red (something like that). Once they're aware of some danger, a dead buddy or something, they'll engange, which is they'll start to move. All without an extra trigger, so a doFollow is only necessary if nothing happened, yet you still want them to move freely again, well, not so free, because it's back to formation then. So that's all fine. Question is if we can further fine tune the engagement of units. Do they engange on their own? Or do they engage due to the leader telling them? And if so, can we disable the leader from issuing engage orders, s.t. units would only ever move if personally threatened or something? Might be worth a shot. Anyways, if in doubt and you need that officer in place there at his desk, disable pathing it is. Otherwise... @avibird 1 ...cool beans. And yep, a good mix might be nice. You could also try to write a simple FSM that keeps switching between the two states (using a pool of good resting positions/choke points) at some slightly random interval. For the extra surprise buttseks.

@avibird 1 try something like this to reactivate them: { _x doFollow (leader _x); } forEach [u1, u2, u3, u4]; after having initially: doStop this; them (assuming you put this individually into the init line of the units, alternatively iterate over them with forEach). Now, I'm not quite sure since I never use the editor's init line, but you might have to wrap this stuff up in a spawn block, as in: [] spawn { <put code here> }; Make sure you only refer to _unit where it's (locally) defined, or create a global variable instead. Anyways, if you got this working with disabling/reenabling pathing, then you can just replace the enable with the doFollow, and the disable with the doStop part. Or use the command variants, if you like.

How climbing should be implemented: All "men" can climb, but climbing is super fatiguing (the more steep/higher gradient the more fatiguing). Your stamina bar goes towards null/exhausted means you lose grip and fall. Whether climbing action can be started depends on a minimum and a maximum gradient. The latter might be somewhat dynamic with respect to the stamina of the unit. These are the basic rules. If tweaked just right, the assistant heavy machine gunner will not be able to climb more than a meter or two in height. Meanwhile a light soldier will be able to free climb for many meters. But not any route will be feasible since a too steep/high gradient will drain fatigue almost immediately anyways. Climbing properties may be altered with utilities/tools, such as a rope: A rope (and similar) has two effects: 1) it reduces fatigue while climbing, and 2) it provides a secure halt, which means that the unit no longer falls to certain death if out of stamina, but he has to wait a bit and catch some breath. Certain climbing tools might not need to be deployed (e.g. a climbing iron) and only provide one, or the other (maybe that secure halt could come with a certain probability of failure). And in consequence: A ladder is nothing special any longer, but a climbing tool just like a rope. No mouse action menu fiddling, but native (better integrated) climbing action. AI also need to be able to climb and plan their routes with respect to fatigue/their stamina and the possibility of a secure halt. E.g. if the latter is not available, then AI is likely to ignore such a route right away, s.t. climbing for AI (unless configured/scripted otherwise) will be more of a last option kind of deal. Latters offer a very secure halt, and AI should be happy to climb them.

C.. can we have this for the trucks/kamaz too just to make the seats go away for a full cargo area? It's super important.

If you've disabled AI then just enable it again: _soldier enableAI "PATH"; And if you've just stopped them, issue an: _soldier doFollow (leader _soldier); (or commandFollow - for the bossy ;) Either store the affected units first in some global array, or make use of thisList of a trigger maybe.

What's wrong with a good old "doStop _x" (or "commandStop _x" for the bossy)? Genuine question, since I'm really not sure what's the (practical) difference. Would a stopped unit still move under certain circumstances, whereas a path disabled one wouldn't?

A "strict" mode for the editor that upon preview/playing immediately aborts anything he does on the first (script) error encountered and goes back to the editor (within miliseconds). It annoys me to wait for the game to finish with my awesome init script and loading up the world and what not, only to go back and fix some stupid error. Pretty sure some precious seconds could be saved, piling up to hours, days even over the years... :P

Absolutely not, no. If an object is functional within the game world, and can manipulate it in the way a user expects he should be able to, then it's not just smokes and mirrors. It turns "real" (with respect to the game world of course). Sure, it's not black and white, it's a spectrum. And what detail is really needed (or expected by users) is up for debate. Should we be able to cut down individual trees with that axe object? Does a milsim need this? Questionable. Probably more something for DayZ and the like. So it stays a "smokes and mirrors" object (maybe someone writes a script, but that's a different discussion...). Same with buildings: do we just need them to populate the terrain, which reduces their function to that of a huge rock (still something, I guess...)? Or is the interior of buildings valuable to what we're trying to do here?

My impression is rather that this was simply a question of priorities - unfortunately not a very high one. For example take the two largest buildings from that hotel/resort (tiny island top NE). They'd be really great, weren't it for the fact that parts of both of them are closed off for no good reason (thereby drastically reducing their utility for mission makers). Why do that? Why would anyone do such a thing? To save time. Or take the huge yellow haul trucks. Why can't we drive them around (man, that would be so sweeeet)? Missing parts, yada yada? No. To save time. It's really a shame to save time by reducing functional objects to mere decoration. I love Tanoa (haven't been around for a while, so I'm still exploring). The forests/jungles are simply the best (boy, do I hope we'll see similar dense forests with more northern/european, maybe alpine vegetation). It's all so friggin pretty. And then you take a closer look and lot's of stuff is just "fake". A "cardboard city/object". It's very unfortunate. Then again, close quarters combat (or similar things "this close up") was never really a priority (and the terrain, to the contrary, is of very high quality; from a functional/tactical pov). And it was never supposed to be tackled for A3, seeing how they "solved" the problem with fancy video sequences for such stuff you can't really represent ingame (e.g. your cheesy door breach, throw nade, shoot and arrest scene). Not really happy about this... it's all just smokes and mirrors. Ingame machinima, known from earlier releases in the series (gib guba back!), are much better, more honest, anyways. meh... :) EDIT: And just because it's such a good example, here's a screenshot from the hotel resort building. Red dots indicate all the building positions that aren't available (closed off rooms/closed doors), but really should be. What makes me an especially sad rambo here, is the fact that you could easily step (hit "v") onto the roof from the balcony for excellent overview position (just for the players, not the AI, eh). Alas... :( The other building right next to it is also just frustrating, with it's main room not being accessible, only the entrance or something? Just.

So, there's this promising command selectBestPlaces, but once more the documentation is barely useable. The search here didn't yield a single hit either... But fortunately I've scanned config.cpp some time ago, which enabled me to get some idea what expression in this context could mean, so excuse the little digression: cost/probability expressions in config.cpp There is the subclass Ambient in config.cpp containing definitions of all the small animals, and an - tada - expression (named "cost" here) that defines, where and when these animals may apear (all guesswork of course, so don't take this for granted). The cost for these is a simple function (or expression) returning scalar based on simple arithmetic and some interesting keywords serving as variables of the sampled positions. The higher the output of this function, the more likely is it, that such an animal gets spawned at the sampling position. (plus there are again subclasses of these, where the cost is usually set to 1, while we have another expression for "probability" where `more exclusive?` keywords are beeing used...) The keywords used in config.cpp are: forest trees meadow hills houses sea night rain windy deadBody Each of theses variable in an expression will be replaced by the actual sampling value at the sample position of this factor, ranging from 0 to 1, where 0 means not at all and 1 means totally! (which allows for easy arithmetic combination of multiple factors) Thus we can mix factors from three major different dimensions: the geographic dimension, time and the weather. (plus the deadBody thing, which looks like a "bonus" dimension implemented especially for the flies) Some short examples: deep forest: "(1 + forest + trees) * (1 - sea) * (1 - houses)" tree, but not in forest: "(1 - forest) * (1 + trees)" hill, no forest: "(1 - forest) * (1 + hills) * (1 - sea)" house on hill: "(1 + houses) * (1 + hills)" ... This is how leaves get spawned where trees are near, while the game spawns rocks where hills are located (clutter particles). And this is how the HouseFly finds deadBody, DragonFlys the forest and ButterFly the meadow, while the birds disapear in the night or in the rain. Some examples, taken from config.cpp: class BigBirds { radius = 300; cost = "((1 + forest + trees) - ((2 * rain)) - houses) * (1 - night) * (1 - sea)"; class Species { class Hawk { probability = 0.200000; cost = 1; }; }; }; class BigInsects { radius = 20; cost = "(5 - (2 * houses)) * (1 - night) * (1 - rain) * (1 - sea) * (1 - windy)"; class Species { class DragonFly { probability = "0.6 - (meadow * 0.5) + (forest * 0.4)"; cost = 1; }; class ButterFly { probability = "0.4 + (meadow * 0.5) - (forest * 0.4)"; cost = 1; }; }; }; class SmallInsects { radius = 3; cost = "(12 - 8 * hills) * (1 - night) * (1 - rain) * (1 - sea) * (1 - windy)"; class Species { class HouseFly { probability = "deadBody + (1 - deadBody) * (0.5 - forest * 0.1 - meadow * 0.2)"; cost = 1; }; class HoneyBee { probability = "(1 - deadBody) * (0.5 - forest * 0.1 + meadow * 0.2)"; cost = 1; }; class Mosquito { probability = "(1 - deadBody) * (0.2 * forest)"; cost = 1; }; }; }; class WindClutter { radius = 10; cost = "((20 - 5 * rain) * (3 * (windy factor [0.2, 0.5]))) * (1 - sea)"; class Species { class FxWindGrass1 { probability = "0.4 - 0.2 * hills - 0.2 * trees"; cost = 1; }; class FxWindGrass2 { probability = "0.4 - 0.2 * hills - 0.2 * trees"; cost = 1; }; class FxWindRock1 { probability = "0.4 * hills"; cost = 1; }; class FxCrWindLeaf1 { probability = "0.2 * trees"; cost = 1; }; class FxCrWindLeaf2 { probability = "0.1 * trees + 0.2"; cost = 1; }; class FxCrWindLeaf3 { probability = "0.1 * trees"; cost = 1; }; }; }; ...you get the idea. And as it turns out, these config entries (cost/probability) will be feed to exactly this selectBestPlaces command. selectBestPlaces Thus, I may (with some surety, based on my experiments) complete the documentation for this command: selectBestPlaces [_position,_radius,_expression,_precision,_sourcesCount] Parameters: _position: sample position (2d position seems to be sufficient, so no ASL position needed) _radius: defines the area to find the positions in (scalar in meter) _expression: cost function (string, not code!), calculated for every sampling position returning a positive number. The higher (positive) the value, the better. Zero means that the expression does not apply. The expression can rely on any of the variables in: [forest, trees, meadow, hills, houses, sea, night, rain, windy, deadBody], maybe more. _precision: sample precision/ radius of the sample position (scalar, maybe in meter, but for sure this is no 0 to 1 range). Given a precision of zero, your game will probably halt for some time, most likely for ever for you basically try to divide by zero. I guess we divide the area by this sampling area the precision/radius defines. With a very low value, you may get a lot of "bestPlaces" very near to each other - the precision as min. probably. With a greater value the returned positions are much further apart from each other, though it looks like the min. distance isn't exactly the given precision interpreted as radius... But you get the idea. _sourcesCount: number of best places returned (integer) Returns: No, you won't get an array of positions. You will get an empty array in case no best places were found (I guess this is true, when all "costs" where exactly zero) OR an array of "bestPlaces", where "bestPlaces" is an array of: _this select 0: position _this select 1: cost (expression result at this position) Now be carefull with the sampling radius and precision because selectBestPlaces gets computed in one go and doesn't suffer from any maximum runtime-cap each frame. Thus if you're precision is too small for a too large sampling area, you may freeze the game for several seconds! (too many samples taken, plus all these samples need to be sorted too, to return the "best" ones, of course..) Oh, after a first unsuccessfull regex search for an official example, I actually do have found just some, all from the animal module (of course, DO!), in Animals_main.fsm: _root = configFile >> "CfgVehicles" >> "Goat"; _favouritezones = getText ( _root >> "favouritezones"); _randrefpoint = [(getpos player select 0) +Random(2*_SpawnRadius) -_SpawnRadius,(getpos player select 1) +Random(2*_SpawnRadius) -_SpawnRadius]; _PosList = selectbestplaces [_randrefpoint,_FindPlaceRadius,_favouritezones,10,5]; _PosSelect = _PosList select (floor random (count _PosList)); _Pos = _PosSelect select 0; So there you go. Happy selecting best places. I imagine this is an elegant way to solve similar problems of finding appropriate places randomly. And in case some developer pops in, I'd like to know if I've mention all of the available sampling-variables? What's really the meaning of precision? Or anything else, that I got wrong... so once we have the facts straight, we may complete the wiki about it.. :rolleyes:

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.

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.

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?!). :(

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:

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...