rübe

Maybe a bit more intrusive, but you could also try to adjust spotTime/spotDistance skills. Introduce some weatherVisibilityCoefficient, keep some initial base skills on units (setVariable), and iterate over all units (from time to time). ..then again, I'm not sure how good you can cripple the AI in this way.

Some general feedback: Usability: please streamline modifiers, s.t. I can hit shift (to rotate) even if I already have something selected (i.e. placement/moving is currently active), thereby going from placement/movement mode to rotation mode in a heartbeat. Currently I have to stop placeing/moving first, then hit the modifier, and start dragging again, where as just hitting the modifier should do to toggle modes. Undo, yay! But my "Ctrl-Z" doesn't work, it's "Ctrl-Y" over here... meaning my swiss keyboard-layout (or anything else than US for that matter) isn't respected. About weaponholders: placing single weapons works, yay. But why is there a single magazine spawned below, individually (not already loaded)? The weapon should spawn empty, unless otherwise defined. Next: we probably also should have the option to spawn individual magazines. That seems to be missing currently. Option to open/close doors. Option to destroy the environment (i.e. map objects such as street lamps, windows, buildings, ...) How can we add/remove objects to/from a selection of objects? Can we group/ungroup them? If a unit is selected, it should also be selected in the entitiy list (to the left). Some bugs w.r.t. models/objects: "Crates (Plastic)" oscillate in altitude while placing/moving along the xy-plane. "Workstand" seems to have no surface defined like tables, and thus objects placed on it fall down once simulations are go. One thing that probably could need some more streamlining/tooling are compositions, now that anyone will be able to easily put them together. Export everything (or just the current selection) as "free" or "anchored" compositions. A "free" composition is just a set of objects that can be translated to the desired position like current compositions. "Anchored" compositions, on the other hand, would need an "anchor" which can be substituted by any object of the same class. Positions would be relative to such an anchor object. And such an object could be a world object (already on the map), or an object placed down in the editor. The best use case I can think of would be compositions for interiors of buildings. Decorate one building, and now you have a composition for any building of that class that can be spawned as seen fit. Quickly you end up with a (tagged) library of interiors. What if we just could select an empty building and spawn some composition for that class of building? What if we could easily extend and share such compositions? Let us shape the output of exported compositions in some way or another. E.g. we should be able to export an sqf that holds an array/the data of the composition, such that custom spawn scripts can easily make us of it. Maybe we'd like to dynamically spawn different objects (depending on the desired faction, or randomized). P.S. Now that people will put down even more (small) objects, please consider fixing the range/reach of the inventory. Case in point: multiple items on a table, a weapon, a scope, magazines, maybe a helmet and a binocular. And now try to grab the stuff. <_< Two problems here: Selecting a specific item is super hard. Only a single option to grab some item will show up at a time, but it's hard to control which, since items (or their action bubbles) seem to fight each other. Now, this wouldn't be so bad if it weren't not for the second problem... Open inventory. Only a single item shows up to your left. :mellow: This is just annoying. Please make sure that all items within some graceful radius will show up too, even if those are all separate weaponholders. I can see that we probably do not want this behaviour with ammoboxes, there you probably just want to open one box at a time. Fine. But with small items on a heap, this is different. And given how popular looting is now a days, this probably deserves to be fixed. ...oh, and maybe it's also a good time to patch up all small items and make them effective by default, s.t. that we can grab/take them and attach custom actions to them. Just like with those few intel items (but without "intel added" callback).

Disabling fatigue can't be the solution. But true, it's a bit unfortunate that fatigue was added a bit late, thereby breaking quite a bunch of existing scenarios. Adjusting (default) loadouts and maybe even group compositions is probably one thing to look into and reconsider. Another part that probably should be fixed is default AI group movement. Now that individual endurance/speed is this pronounced - and let's face it, we not alway have homogeneous groups - AI leaders need to pause/rest and wait for the weakest/slowest units in their group. Make sure to take a defensive/low position while resting, maybe use already rested units to do some overwatch/patrol kind of thing. Some small, lovely subroutine. The result is not only groups that move with speed (instead of being constantly exhausted by not managing fatigue), but also some more micro-AI. Btw. maybe a groups speed could be adjusted (or set to dynamic) s.t. the fatigue level of the weakest unit doesn't exceed some threshold, with the result being to go slow(ish; not "SLOW"), but steady (and never (fully) exhausted). The good news is that you can do pretty much all this already now (with some simple FSM, checking fatigue levels, etc.), but you'll have to carefully design your missions around such stuff. So, IMHO, fatigue management should be implemented by default, at a lower level (with behaviour-params to adjust maybe). Oh, and also make those guys lower the weapons more often/more reliably. Especially given, say, MOVE-waypoints with some distance. A "reasonable" speed could be easily calculated, I guess. But granted, that's a bit a different concept than "SLOW", "NORMAL", "FAST" doctrines. But given they're currently borked and "everything" plumets to "SLOW", I don't see why we shouldn't take the risk. :lol: tl;dr: maybe try to not disable fatigue, instead adjust loadouts/group compositions, take a truck, :P , try some FSM sorcery in the meantime, and hope that BIS implements some kind of fatigue management for AI leaders/movement, with special care for heterogeneous groups, that is, units with vastly different loadouts/endurance.

I'm not sure if just a set of new, better textures will do. ^_^ What about the currently available/implemented particle system itself? Is that still state of the art? ...or, what about 3rd party solutions? :wacko:

Lovely stuff in here. That blizzerd is just jummy. :lol: ...at some point BIS just gotta do an official snow thingy, and finally implement this stuff (temperature -> rain/snow; AI perception w.r.t. particles) for good. Some shiny day. :rolleyes: And yeah, these effects need way too much single particles to be effective, which can go south really fast if you also throw other smoke resources (fires, explosions, ...) in the mix. Seeing how particles get "cut off" due to reaching the limit can be rather immersion breaking, to say the least (pls don't try command view, bwaha). So... I don't know, but maybe a different/pimped particle system could help for such effects (maybe just using fewer, but larger particles, with better/carefully doctored textures?). The current one isn't the youngest (neither are the textures available; see over here, eh), and surely there must have been some (general) progress in this area of research, no? Maybe DX12 stuff could help too, at least with the number of particles? Tweak on!

Nice minimal setup. So it looks like: The moment a single unit spots an enemy, all unit in the group are informed that there is an enemy around - immediately, but... ...each unit has to individually spot/see the enemy. While this is rather reasonable, I do see a problem with the first point: team members should really not be informed/alarmed the moment the detecting unit gains knowledge about an enemy. There needs to be a timeframe where such a unit can be taken out without having the rest of that units group be alarmed. Granted, we can argue that a unit gone missing (radio silence for too long) will still cause an alert state of the whole group, but that'd take even longer. Maybe there should be an indirect messaging system that notifies the rest of the group after some delay, but can be cancelled in case the sender is dead in the meantime. Similarly one could have a second message with an even larger delay, that can be cancled by recieving the first message (i.e. only fires if the unit is indeed dead and went missing). And that just for knowledge sharing. Usual AI commanding would not be affected by such a tweak. And then, ideally, such communications would be tied to animations, where we could actually see/observe the AI from making these "crucial" radio calls (and prevent them from doing so in the first place). Finally there should be means of linking up different groups, s.t. they can share knowledge too.

Well. A bullet that impacts somewhere near you might have come from pretty much anywhere. A bullet that hits you right in your butt does carry a bit more information, now doesn't it? But I agree, that information is gathered, processed and distributed to group members way too quickly and reliably.

Ah, yeah. I can see how AI commanding (and scripting) get's much more complicated, once communication channels would be modelled and required for AI commanding. Then again, that only applies to a group (inner-group communication). Modelling inter-group or group-hq communication, however, would be still possible without that "always has a radio" premise. And maybe inner-group communication could at least be adjusted with some parameters/functions (communication delay, ...). So maybe not for ArmA3, but I hope you guys will think about communication channels while planning the next iteration. IMHO there is a lot of potential for better, more believable AI and meaningful dynamics, easily and quickly setup in the editor (or scripted) just by defining some communication-channels (granted, now that I think about it, this sounds a lot like "high command" for AI).

Maybe. :) Then again, ArmA is no Super Mario (I'm sure you've seen plenty of AI playing 2d-sidescrollers). The environment can't be learned, since it's not static (or deterministic), but highly dynamic. We can't just use a "simple" fitness function optimizing some score (like distance reached in a 2d-level). The question is what the AI is supposed to be optimizing/maximizing? Combat effectiveness? Some combined score? Or should some error (deviation to "human behaviour") be minimized? We probably do not want to end up with AI that finds new and effective ways of combat, if it looks silly and wrong (e.g. exploiting glitches/bugs). The goal, afterall, is to model soldiers (and real, or believable, behaviour/tactics). But you make good points: there are indeed many low-level decisions that could be driven by ML: spotting decision, shooting decision, and such stuff. And maybe for such small problems (or subsystems) ML could be employed in a much less restricted fashion (i.e. unsupervised). I just doubt that ML is the right tool to model AI on a holistic level, since again; we do not want to breed a new species, but rather mimick something we already know. It's not about the abstraction level where ML can be introduced (first). It can be low-level or high-level - what matters is that it's a confined subsystem where we can formulate reasonable goals to be optimized. Exactly. But there is no single "human behaviour". There are many different roles that could be trained. Training data thus should be plug'n'play (per unit or group). And there needs to be a streamlined workflow to let mission designers easily train new roles as they see fit (besides having a set of pretrained roles by BIS). Imagine if missions would (partially) come with their customly trained AI? Bananas! :D

You could certainly put machine learning to some good use in AI decision making - so exactly the level (and up) Rydygier mentions. This is not about basic movement, spotting, aiming and shooting stuff. And it's also not only about group-AI (such as flanking), but also about inter-group communication and interplay (think guard waypoint). Lot's of fancy machines could be trained (rnn, decision trees/forests, svn, hmm, ...), and for a start maybe rather offline(-ish) and not online, while actually playing the game. Training might be very costly (even incremental), but querying such little blackboxes isn't that expensive (well, there is the memory, still...). I can imagine a rather tiny, but very high level feature vector could already work reasonably well (getting clean and potent information in a computer game is rather easy...). But encoding answers/reactions, seems to be already way more difficult, especially in a generic/general way. But sure, I could see mission designers train some AI for their missions in a bunch of sessions: setup a scenario, do your stuff, and repeat a bunch of times, while slightly altering the scenario (to model different stimuli and the reaction you'd like to encode/train). BIS could train stock AI behaviours and incrementally update them, maybe just based on some special server logs... Well, the time will come. I expect to see indy games go first in this direction with games based on ML as core gimmick. For mainstream games it's probably still way too early: all those fancy little blackboxes are hard to understand, train and integrate (in a meaningful way/as you want) and debug ("debug"). That's quite some risk to put such a thing into your game (i.e. highly experimental/not recommended).

Yeah, I also believe that "information sharing"/communication isn't adequately modelled, be it inner-group or even faction-wide communication. Maybe even some nasty bug has sneaked in in this regard. Who knows, inner-group communication might currently just be broken. Question: do the equipped radio (items) in any sort or way affect AI "information sharing"/communication? Like... at all? Would a "guarded by"-waypoint be affected by units not having the radio item? Either way, I see lot's of room for improvements here. AI can move and shoot just fine. The problem arise mostly on a higher level: what are they doing and why? Thus shouldn't there be an easy system allowing mission makers to model means of communication? I'm not talking ACRE here, but an easy way to link up groups or factions even (maybe an additional radio-item would come in handy). You know... like something better than a "guard"-waypoint? If 5 groups are guarding/patroling some strongpoint/common AOO, we probably wanna have them in constant (radio) contact. We should be able to easily model that in the editor (or by means of scripting - of course). Similarly, and a level higher up, there should be a way to radio for backup/assistance/help. Again: the "guard"-waypoint should be deprecated. Give us something better, where we can define which guys "on guard" are responsible for which groups possibly calling them. Maybe let us define the delay-time from observation (of a threat) to reaction (radio) similar to trigger timeouts (easy stuff for the editor). And make sure that things do not work without equipped radio (maybe introduce another model/item). What if we could link some communication channel (say from group A to B ) to some object (like an antenna) that needs to be alive (and could be destroyed). Given the dynamic nature of ArmA, information sharing/communication should be a driving force in AI decision making (high level). Now sure, one could argue that it's perfectly possible to customly script and model all this right here and now (surely it has been done already, in one way or another). IMHO it should be a part of the engine, seeing how closely related to AI it is. And I'm talking way beyond flanking maneuvers of a single group. What if group A, facing a tank, has no AT, but could check in with HQ, if someone else could maybe assist. Group A would go duck'and'hide (and maybe laser pointing some targets), while CAS (or artillery, or...) is called in (some group B put down on some airport and comm-linked to HQ; maybe even registered for very specific tasks/requests). tl;dr: Let mission designers quickly link groups (2 layers: layer 1 to merge groups in a common AOO, layer 2 to link up with HQ), thereby defining/modelling communication channels (finetuned with radio items or linkes communication objects such as antennas) and have some easy message passing the mission designer could configure (requests/on guard). Then let BIS fellows work on inter-group AI, which currently is not possible/has to be scripted on top of the engine. Sit back and watch impressive AI reactions and interplay! But at the very least: fix inner-group communication. ;)

By default you can only wear cloths by your own faction, ...which is why Rydygier has some mods to recommend (see main post). Then again, it's not that bad to live with this restriction, so you might as well get used to it.

You also might want to consider looking for existing (military) buildings on the map, instead of just looking for some empty (and flat) space. From there you could just populate that building and look for flat and empty spaces around it (or roads, or...) to spawn further stuff. If you're going down the route of populating specific buildings, make sure you're comfortable with modelToWorld which allows you to position stuff relativ to (static) buildings. E.g. to spawn furniture or sandbags or camonets outside touching the walls, and such stuff. On a side note: it's rather hard to spawn highly dynamic compositions and make it look alright at the same time. While certainly feasible (to some degree), you might want to have a look at X-Cam (or wait for the official 3d-editor) to maybe put some sub-compositions together manually by hand. You can take measurements to then spawn the same composition translated (and rotated) to somewhere else. Maybe also have some dock-points to work with or something, in order to combine such sub-compositions. And if you start just with a flat and empty space, there is the whole question/problem of layout (it's a fun one though with many creative approaches). In order to have sandbags, fences or minefields around such a base (at least partially), it's always nice to compute a convex hull (and add some border/margin), say as opposed to simply spawning stuff circularly with a fixed radius. Have fun. :D

I'm not sure I'd use a trigger - whoes condition gets executed/checked every frame - for such a thing. Why not spawn a simple FSM (or just a script with a while-true-loop), and then check with nearestObjects using a slightly larger radius maybe, but also a longer delay to recheck again (maybe every 3-10 seconds). Also make sure to randomize the (start-)time of the say3d commands a bit, either by sleeping for some time between multiple calls (using a queue), or you could also spawn a new thread for each unit with randomized sleep before saying something. And then you might wanna mark units that sayed something (the last time), to have a cooldown per unit. Maybe even filter randomly, s.t. only every nth unit will say something (just in case things are too much, or too robotic/predictable). Other than that, I have no idea why your trigger doesn't seem to be working. Oh, and: in your script above you seem to be picking a sound at random only once(!), then that sound will be used for allUnits (well, this turn/cycle. I guess multiple civilians could end up there at the same time...). I don't think that's what you really want. Randomly picking an element out of an array is cheap, so maybe put it inside the foreach loop. ;) Hm, why are you using allUnits anyways? Shouldn't the trigger give you a list (thisList) including the units that triggered the thing? That should do it already.

It's indeed hard to improve (default) behaviour without compromising and losing generality. This wouldn't even be a problem if it weren't so hard to model different/extra behaviour on top of the default one. I'm sure that one can model behaviour with skills to some degree, but I doubt this will really cut it. Have you guys ever thought about introducing a set of AI rules of engagement (ROE) values, complementing the skills stuff? Should units shoot unidentified units on sight, no questions asked? Or should they be more calm, only opening fire if needed/shot upon? How about active/aggressive vs. reactive/defensive combat behaviour on a scale from 0 to 1? Should units engage enemies once identified? As in flanking and stuff? Or should they rather sit tight? Does a group use the bounding overwatch dance or rather run and gun? ... This would also be an opportunity to implement different (default) faction behaviour. Strict ROE and tactics for the well trained guys, not so much for guerilla dudes.

Reaction time alone is not good enough, I'm afraid, or we'll end up with units looking somewhat ridiculous. IMHO it's important to also have a visual cue about what's going on in the mind of an AI. Being alerted, alerting others in the same group (to look somewhere), maybe use the radio (if in safe and not already in combat mode), small gestures, looking around/observing, maybe taking a more defensive stance/position for a moment. Such little things.

If this bug here (lights/lamps vs. savegames) would get fixed, I'd be so happy. ^_^

Yeah, or you can issue them a doStop, which results in units that stand still *until* contact with the enemy is made, at which point units probably will leave their positions (in case the leader issues engage orders) and move around - which also might be a nice behaviour. At least I'm not really a fan of units being fixed somewhere (IMHO that's more something for static vehicles; use 'em ;)), to then simply drop to the ground upon contact. But of course you could use both approaches. A good mix of fortification objects, static vehicles/mgs, and then patrolling (maybe some hidden backup units a player wont see at first - released upon alarm), doStopped and maybe even some forceSpeed-fixed units should give you a lovely result. :)

The problem is that we can not simply adjust the deployed weapon (horizontally) in small increments (and within given bounds). No, we have to undeploy, move a bit, redeploy and see if it's any better now. If not, then undeploy again and start over... Shouldn't we be able to horizontally move a deployed weapon a bit?

What he said ^^ :lol: Also try to tweak spotTime at the same time. And, last but not least, you can always make sure that individual soldiers are facing some certain direction, watching some boring object, s.t. you can then go on and easily stab em in the back (coward!). Then again, I'm not too sure about the side-effects (i.e. when/if they'd snap out of it, w/o some explicit stimuli :unsure: ). N.B. I also find it rather odd that 0 does not represent zero skill. Taking the example of spotDistance, we can not model a blind guy (hey, maybe just temporary for some fancy boom in yer face after effects script, who knows?). And that's kind of sad. I don't get the argument that units shall remain "functional", no matter how low the skill. Mission designers surely know what they're doing (well, not really, bwaha), so that's a non-issue. What's important are reasonable *defaults*. That's it. And then, if you have a normalized 0-1 scale, make sure that 0 indeed means 0 skill - up to being brain-dead. So what? -- end of rant. B)

^^ okay. :lol:

Ahh, yes. This is already much better. Still, I think the post date (e.g. "Postd Today, 11:41) is still off. For one it should be next to the post number in the thread (e.g. "#930"), and so, for two, it should be also in the sidebar. Maybe put both at the top of the sidebar, and above the username (which still is much larger)? Then we just need to have that "like this" button merged into the lane with the "report" and "quote" buttons. Maybe make it so that the report button floats/aligns left, the others to the right, or something. ^^ Two more lines we can easily get rid off (per post!). B)

First I'd suggest to create an "init.sqf" file which get's called before the mission starts. Then you can put things like this: init="recon = group this; power = true; bluefordetected = false; power = true"; there instead. Guess the "recon = group this;" part is fine, but power (listing it once should be enough) and bluefordetected stuff does not really belong here. Now that you have an init.sqf file with something like this: power = true; bluefordetected = false; // ... you can for example spawn a thread for debug purposes that monitors these conditions. So instead of having all these triggers with stuff like this: expCond="this && ((alive teamleader) && (bluefordetected isequalto true) && (power isequalto true)) "; expActiv="hint ""Teamleader is alive, they know you are here and have power"""; you could make live way easier by simply spawning a single thread that writes the state of your mission to the RPT file. Keep some tail-tool running (BareTail for example) to watch the output while playing, given you have a second monitor or are testing the scenario in windowed mode. Or, if you like that better, make use of hintSilent. Anyways, this could like this (in the init.sqf file): [] spawn { while {true} do { diag_log text format["alive: %1, detected: %2, power: %3", (alive teamleader), bluefordetected, power]; sleep 2; }; }; Adjust the delay (sleep x) as you like. If there's indeed a need to be notified only if these values change, then simply keep a private copy and then only hint (or diag_log) if one has changed. E.g.: [] spawn { _power = power; // private copy of initial/current state while {true} do { if (_power != power) then { hintSilent format["POWER: %1", power]; }; _power = power; // update last known state sleep 2; }; }; You get the idea... Anyways, once your scenario/mission logic starts to deviate too much from a linear story (or get's too complicated otherwise...), I'd really encourage you to start looking at FSM and making good use of them. FSM are really awesome to handle the flow of a mission (or other actions) and they're easy to use too. Which could look something like this: Note how: The mission can be completed by being detected first, then the power goes out (1), by killing the power first and then still getting detected (2), or by killing the power and not getting detected at all (not the transition to "stuff"). The power has to be cut off, or "stuff" can't be done and the mission never be completed. There is a transition to the dead teamleader from all intermediate states, and then the mission is lost. Put debug hints (and code - of course) in any state you like. Give it a try, FSM are really the best for mission flow. It's easy, fast and fun too! :)

Yeah, this can be really ugly. One variable missed to make private, things work fine for the time being, and then, one shiny day, it comes back to bite you in your ass. In retrospective it might have been way better to implicitly declare any variables private, while having to explicitly declare variables that creep down to global scope. This is one of the reasons why I liked Mac's Squint so much. Too bad it's no longer maintained.

^^ This sucks. :lol: