Romolus

A FSM doesn't do that either, that's my point. What does make it override the standard movement is the formation and danger hook in the config. Whether you create a FSM that implements that standard movement or if you just create a FSM with only one state that calls a script, it doesn't matter in what you can do. The only reason you need a FSM in the first place is because BIS has a graphical editor that makes it easier than just writing some scripts. So the engine requires a FSM to be called from those hooks. But the part that does all the work in a (scripted) FSM is plain old scripting. The part that the FSM does is just switching states and running the conditions (which are also plain scripting commands). So the part that the actual FSM does is nothing else than loops and conditions in a script. So instead of wondering about FSMs I rather think about what kind of things can be done with the new AI scripting commands, because those are what does all the work Also the problems I mentioned don't have much to do with FSMs either. BIS could just have taken plain scripts instead of FSMs so that a script would be called by the config hooks and the doFSM and commandFSM command would be obsolete. So there's not that much about FSMs to be thought through. The main thing that gave us more control over the AI are the scripting commands like setDestination, setHideBehind, setFormationTask and the like. Those are the commands used in the formation.fsm and those are the ones that are directly connected to the AI. Not the FSMs, those are just a mere shell for the commands. Actually what you're describing about addons, addon makers and mission makers is exactly what I meant in my previous posts. Of course everyone will be using those new AI commands, because you can do so much more with the AI now. But the way it's currently implemented leads to problems with incompatibility between addons and severe limitations for mission makers - if nothing is done about it. I'm not screaming that it's wrong anf it needs to be fixed, I'm just saying that something needs to be done about it. Hence my suggestion about the scripting hooks for FSMs. In the past, there were many approaches to get some kind of common standards into OFP editing and not one if them really took off because of various reasons. So I don't really believe that we'll get some kind of standard for the AI scripting either because people are just the way they are. Also a common standard for addon FSMs don't really solve the problems for mission makers. In the past, usually the people who created the addons didn't do much of the mission work. The exceptions were more or less all complete conversions where it was also difficult to use them in combination with other addons. So the bulk of mission makers will experience severe limitations in what they can do with addons if addon maker start using the new AI commands in their config attached FSMs. That's why I think having some scripting hooks that can enable/disable the AI FSMs temporally could be a rather simple solution for all this. Just like the switch included in the most addon scripts where the mission maker can disable things he doesn't want to have in his mission. Since that was more or less common practice, I think somehting similar could work for the AI FSMs as well. Addon makers could create their AI FSMs that do what they think their addons should be doing, and mission makers can disable them to get the things done that they want or even create scripts to make addons with incompatible AI FSMs work together again. An even better solution in my opinion would be to only create a stub-FSM that calls a script stored in a global variable. That way a mission maker can put his own script into that var and it gets called by every unit. The script can then do what the mission maker wants or just call the original script that was intended to be run with the unit by the addon maker. If the addon maker creates the AI behavior as a FSM attached to the config via the formation or danger hook, then this FSM can't be called in a script via doFSM or commandFSM because the input parameters that the FSM gets form the config hooks are different than what the doFSM or commandFSM commands deliver to the FSM they run. Nor can it be overridden if it doesn't do what the mission requires. But maybe someone else has an even better solution, so that's why I posted those things in the first place. I'm sorry for assuming that you suggest a single big FSM instead of scripting hooks, but since you didn't agree that we need some ways to interfere with FSMs, such a huge all-including FSM seemed the only possible solution to counter the problems I mentioned (beside getting all addon makers and mission makers agree to common standards which I don't believe in being possible).

@CrashDome: You're tip-toeing around the issues instead of addressing them in your comments So how would such a "well done addon" look like in your opinion? FSMs are there to contain AI behavior (at least for the formation and danger parameters in the unit config). So what you're saying is that AI scripting only belongs into addons and those need to be done in a way that a mission maker doesn't need to have any influence on it. So how would you create a FSM that contains all the human behavior that you would expect from any unit in a mission? How do you make sure that you didn't forget anything so that a mission maker would have no need to write his own AI script? How big would it be? Also how many different implementations of AI behavior scripts are there for OFP? Which one would you choose as an addon maker to include as FSM in your addons? What if another addon maker choses a different implementation? What do you do to make sure units from both addons can even work together if they're using a different AI behavior implementation? And what do you think a mission maker would say to all this? What I'm saying is that all those issues (if not addressed) will lead to addons being even less compatible to each other than they already were with OFP. That for mission makers it will be even harder to use addons in their missions, especially when they can't even influence the AI behavior defined in the addons. The only thing I can see that you're suggesting to solve those issues is to create one single monolithic FSM that covers all the AI behavior that is ever needed and to use it in every addon that will ever be made. Don't you think that there would already be much better AI around in games than the basic stuff we see right now if you would be able to cram all the complex AI behavior into a single FSM that is needed to fare excellent in every situation of every ArmA mission? FSMs aren't exactly new in the field of AI programming and many games use FSMs, so why don't we already have that perfect AI unit FSM that you're describing (or not really describing, but rather hinting at)? And again I think you're not addressing the problems that I mentioned It doesn't really matter how it's intended to work, the question is what problems result from exactly that? I'll repeat what I think the problems are: - The use of the DoFSM and commandFSM is limited because they can't be used to override the config FSMs while at the same time the config FSMS can (and most likely will) interfere with what a mission maker wants to do with the AI. Even creating the ultimate FSM mentioned above doesn't make this point invalid. - The use of doFSM and commandFSM is unreliable because the calls are not cued and instead any successive calls to doFSM or commandFSM abruptly end the currently running FSM no matter what state it is right now. How do you ensure that any FSM you're writing doesn't have any negative effects when it's abruptly ended at any state? At best this will limit the things you can do with your FSMs. If your current running FSM for example uses the disableAI command, then does something and then uses enableAI and you want to call another FSM via doFSM or commandFSM then you either have to check whether the AI is still disabled (since you don't know at all at where exactly your previous FSM will be stopped) or check whether the previous FSM is still running. So no matter what, if you want to use successive doFSM or commandFSM calls then you either have to check tons of things or you're headed for trouble. What kind of things would you like to have documented from BIS? Right now we already know that there are basically two kinds of FSMs: Config-defined ones that access hardcoded functions to get done what they need. The hardcoded functions that are used in the current FSMs are rather obvious and I don't think there are much more hardcoded functions that those. Why should BIS include tons of undocumented hardcoded functions when they could just provide them as a scripting command? (Which they did for quite some AI-related commands.) The other kind of FSMs are scripting based FSMs. Those can be called via the doFSM and commandFSM command or attached to two parameters in the config. With those FSMs you seem to be able to use all the scripting commands that there are for regular scripting. The FSMs themself aren't really that interesting at all. Everything you can do with an FSM (a scripted one) you can also do with a script. The only difference might be in performance (can easily be tested) and what input parameters you have access to in a scripted FSM (either called through the config or through the two scripting commands). Those input parameters are and whether there are other config parameters than just formation and danger where a scripted FSM can be attached to, are pretty much the only things that I'd like to get some info on. I doubt there'll be an easy way to create compiled FSMs. Nor do I think that BIS would be willing to provide the tools for that if it would be possible. What makes FSMs a nice thing (if you have a graphical editor), is that it's a more graphical way to code AI scripts and it takes care of some of the control structures that you would need. But that's about it then, I think.

Same as everyone else I guess In this case by experimenting with FSMs and the new AI scripting commands and having a bit experience in addon and mission making. Addons without FSMs don't really work since then the AI isn't doing anything. Now you could completely script that behavior, but that's a far worse workaround than placing scripting hooks into FSMs. The reason why I believe that mission makers need hooks into the FSMs is that it's almost impossible to create a FSM that models the complete human behavior. That would be quite a bit of revolution in the field of AI. So you have to leave some bits out and those will be exactly the bits that a mission maker might want an AI unit to do in his mission. Now he's got all those nice new AI scripting commands in his arsenal compared to OFP, so he could actually get done what he wants in ArmA. If it just wouldn't be for the config called FSMs that use the same scripting commands and constantly override what he's trying to do with his scripts. You can already see this in the many threads about setUnitPos or doMove commands not working reliable anymore. He also can't use the doFSM or commandFSM commands with a self written FSM for his purposes since those seem to not override the config FSMs either. So the only way would be to open up the addon and adjusting the config FSM to do what he wants. Which leads to even more mission specific addons that you need to download to play a mission. We all know how well that helps to play missions. My experience from creating OFP addons tells me that there's no way to create a completely self-satisfying addon. For OFP there were addons with tons of scripts but there were always people who wanted to do even more things with those addons. Now with the FSMs those "features" aren't even optional since they're running by default through the config property. I just believe that addons should be for missions and not the other way round. Missions is what people play in the end so the one who's creating the mission should be in control what the addons do that he's using. If you give him an option to control some kind of "fear level", he still can't use the scripting commands that are available. So why only give him only limited possibilities of what he can do when he's the one who's actually trying to get a mission done with an addon? The most simple case of such a hook would be just a switch that halts the FSM of a specific unit. The mission maker could then just flip that switch for the unit and run his own script without having to fight a constant battle with the FSM overriding his commands. I would agree with that if the doFSM and commandFSM commands would behave a bit different. The way it seems to be implemented right now is that you run one FSM via the doFSM and it just quits in the instant that you try to run no matter at what state or line it currently is. This means that if a single script you're using is calling doFSM you can't use another doFSM call because you never know when your FSM will be terminated and in what state. What would be perfect if FSMs could run in parallel, so that you can have a FSM for that and another FSM for something else that is unrelated to the first FSM. But it just doesn't work that way right now. Right now using doFSM or commandFSM calls in scripts is nothing more than playing Russian roulette. Those are two separate issues: The first one is that you can't adjust config FSMs without placing scripting hooks into them or editing the addon and that they override the regular scripting commands that a mission maker usually has at his disposal. The second one is that calling FSMs from scripts via doFSM and commandFSM is unreliable and limited because successive calls instantly terminate each other and can't run in parallel. I don't think that I'm really pessimistic about FSMs. Just pointing out the current problems for further discussion

The main problem I see is that the doFSM and commandFSM commands are pretty much useless. First because those don't seem to be able to override the config fsms and second because every additional use of them causes the previous run fsm terminate abruptly, which can leave the unit in all sort of undefined states that you can't control. While I greatly appreciate the control we've got over the AI with the new AI commands and the fsm config hooks, I think it will hinder mission makers even more to use addons in their missions just because of the reasons stated above. While it's nice that you can include enhanced behaviors with your unit addons, most time anything special in behavior is highly mission specific. Yet there's no way to effectively override config fsms as a mission designer. So the more addons make use of those nice ways to enhance the AI, the less likely they can be used in missions that need some kind of specific AI scripting. Right now even the standard units give mission makers lots of headaches because of their fsms. The only way out of this dilemma is that addon makers should include hooks and ways into the config fsms to make it possible for the mission designer to override the behavior of the config fsm. But getting this into some kind of standard, looks highly improbable to me. The ones included in the characters.pbo should provide all you need

The Cobra does attack tanks as long as it has some Hellfires left. I've been making a small random tank mission with some Cobras helping out and they do their job just fine. What they don't do is to attack with guns or rockets, but that has to do with their inability of identifying a target soon enough and not being able to handle the chopper well enough to get a shot off. You can see that clearly when you let the AI fly and jump in as gunner on the Cobra. The pilot assigns you all kinds of targets, even infantry, but then doesn't manage to maneuver in a position to fire. Not even with the rotating gun. I remember that for the BAS helos in OFP it was a real pain to get the AI to use the weapons in the way they should and it involved endlessly tweaking the configs of all the weapons until you found a combination where the settings and the maneuvering of the AI matched well enough to engage all kinds of targets successfully. Looks like this didn't change much for ArmA.

Can you elaborate on that a bit? I couldn't reproduce that behavior and I can't remember seeing something like this in the FSM. Actually I really doubt that. The FSM tool seems to only provide the control structure (branching, looping on certain conditions) while the rest is just calling hard coded functions or simple scripting. FSMs are quite easy to create even without any tools (beside a text editor). The main problem is that those are defined in the config and there's currently no way to really override those. The DoFSM and CommandFSM commands only run beside the config FSMs and if you try to override things, there'll probably be some undefined battling between the two. (I didn't do that much testing with those new AI commands yet.) What we need is config FSMs with scripting hooks that allow the mission designer to attach their own scripts to the config FSMs in a clean way or the mission designer needs to create custom addons with special config FSMs if he wants to have some specific AI behavior that gets in the way of the regular config FSMs.

This is already reported as a bug, although I don't think it really is one. The setUnitPos command is used in the FSM of the units and therefor overrides what you set in a script. The same goes for some other scripted AI behavior. The new way of using FSMs for AI behavior offers a lot more control but unfortunately AI scripting like it was done in OFP just got more complicated because of that. (I think searching would have revealed some other threads just about this topic)

Have a look in this thread

The beauty of the config approach was that it worked more reliable. Now with triggers or the vehicles command, you never know whether you really got all units because one might just have gone out of a vehicle right after you collected the vehicles.

The terminate command is used to make a script terminate externally: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_script = execVM "test.sqf"; sleep 5; terminate _script; Actually, I'd prefer the first variant that Gaia posted due to clarity reasons *nudges ColonelSandersLite* Exiting a script somewhere in-between can often lead to situations where you're wondering why the script doesn't do what you want and you suddenly notice that you have an exit line somewhere where it doesn't belong. There are cases where you'd have to run through a ton of other code in some deeply nested loops that can't be avoided, so the exitWith command has it's uses (Although those also tend to be the cases where it can cause the most trouble. That's why I'd always put a fat comment somewhere to remind me of the in-beween exit). But if it can be avoided like with the simple restructuring in Gaia's example I'd always prefer this variant. edit: That teaches me to not take too long to post, as UNN just posted about the terminate command while I was typing

@ColonelSandersLite: I hate to tell you, but in games there's still quite a bit running with the frame cycle. This doesn't make the code unreliable at all. The problem with older games was that they took the frame cycle as time interval and therefor time elapsed faster with more fps. But even that doesn't make the code unpredictable, just unplayable. Having a loop that runs with the frame cycle isn't really a bad thing in a game. I actually think it's a good thing since you as a player can't do anything between two frames anyway, so in most cases it's just wasting resources to do anything faster than that. If you're script is executed once every frame, then that's probably just the right way to do an infinite loop in a game. And about coding standards and messy code: Now you're fighting a holy war here. I'm a programmer by trade and I care a lot about programming standards and doing things the right way for work and personal projects. But let me ask you just one question: Did you do any advanced scripting in OFP? I'd say that at least 50% of the advanced scripting that was done for OFP were pretty bad hacks that would make my socks fly off when thinking about coding standards! Heck if everyone adhered to coding standards in OFP scripting I bet we wouldn't be here talking about this right now because OFP scripting would have died long ago. This is a game of how high you can pile up hacks until either the engine or you capitulate. Trying to adhere to or expecting standards that you know from elsewhere will only make your hair turn grey. @all: Since I can't really think about a reason why I'd need to run an infinite loop faster than with each frame, I'd just use waitUntil. If the engine is bogged down with other things (which results in lower fps), then why would you want to put additional stress onto it anyway by running your loop in constant time way faster than the frame cycle? It might be harder to read for people not used to it but that's not the most important criteria in a game anyway. First it has to run and don't hamper performance and only after that it's allowed to look pretty. There are tons of hacks and nasty things in every commercial game so don't get too fussed about this. Just make sure you know what you're doing.

for OFP it can be done since the file format of the islands is known. For ArmA, we'll have to see how easy it can be decoded or whether BIS is willing to help on it. But even when you can read the terrain, you'd have to create an abstract representation of it that includes all the things you find necessary for the AI to behave in a realistic way. What exactly those features are is what I'd like to see discussed a bit further here. I already mentioned choke points which there are algorithms to calculate them and you mentioned villages and roads. Actually choke points that you can't go around are quite rare in real scenarios as well. What makes those points important never the less is that it's easier, or better for some kind of reason to go though it. If you have a road going into a valley, then you are able to leave the road and just move cross-country up the hills, but then it might be slower. So there is some value in certain terrain. Also if you observe the ArmA AI, you'll notice that it doesn't drive everywhere, even with tanks. But it's not just accessibility and movement speed, but also visibility that can give you a valuable advantage in a certain terrain. If you walk or drive straight over the hills, you'll instantly be seen, but if you keep in forests or behind hills, then the surprise is on your side. There definitely is much value in knowing the terrain and using it for your advantage, even with the smaller scale that we have in ArmA. After all not every mission is located in a village and mission makers choose the location for a mission carefully for providing interesting possibilities that are based on exactly those properties of the terrain that I mentioned. Otherwise all missions that are not located in a village could be played on completely flat terrain without any difference and that's obviously not the case. Villages might be easy to detect and provide an interesting playground for missions, but then we're talking about dynamic missions here and only using villages seems to be an awful waste of the huge terrain and the possibilities that we have in ArmA. Actually, I don't think there is need to further define the type of mission as you will end up with tons of different types and all kinds of variations and combinations, where it should be nearly impossible to rule out one or the other because they all have a common basis. I rather think what we need is to come up with what this basis is and how to get it, so that everyone can build upon it to create his own flavor of dynamic mission. Whether you create a dynamic mission based on realistic guerrilla warfare, or with some specific or artificial game play rules like CTI or maybe even more abstract things, you will still find that you need a common set of things for all of those. Being able to judge the terrain for tactical and strategic reasons is one thing. Something else might be a generic command structure for decisions that are common to all types, or generic group management or group communications. Once things like these are available, it'll be much easier to put some specific gameplay on top of it. There are lots of discussions about narrative approaches in games but the problem is always the same: What you're up with there are books and movies which are both still created by at least trying to come up with original ideas and this is exactly what defeats the approach to create the story by some sort of story-telling engine. The amount of effort you have to put in something like this is way more than what you get out of it since the level of sophistication you have to reach to make it worth a bit is set sky high by movies and books. The thing is that it would be much easier and less time consuming to come up with a new story and create an actual mission every week than getting such a story-telling engine done just to drive a dynamic mission. Apart from the complexity mentioned above, the problem is that cut scenes are a rather artificial method taken from books and movies to help with the immersion. Those need such methods because interaction just isn't possible in those media. In real life you don't have cut scenes. If you want to know something you just go and ask someone, read something or get your information somewhere else. The strength of a game like ArmA is that it's not limited to a predefined plot, but that you can interact with your environment. This is something that books and movies can't do. When DVDs came up there was a big hype about how interactive movies are possible now with the amount of data that can be stored, but from what I've seen this didn't really work out well. The qualities of movies and books are not their interactiveness and the qualities of a game engine like ArmA is not really dynamic story telling. Both can be done with huge amounts of effort, but the question is whether the result is really worth it. I just can't see how such a cut-scene library could be done within reasonable effort and a quality that makes it worth. At least not if the goal is story-telling. Where those things can help quite a lot is to intensify the immersion of a mission, be it dynamic or not. Like when you see soldiers loading something into a truck or doing other duties that are not in the standard repertoire of the regular AI. This is where I can see "actor libraries" could help allot. Not for story-telling or story driving cut scenes, but to provide a more realistic environment. This is much easier than driving a story with it, since those are things that don't require that level of uniqueness to make a significant impact. For the radio chatter library I agree with you. Some time ago we had a discussion about exactly that in BAS and the only thing that is missing for something like that are some people who are willing to do the voice-acting and someone who has a clue about doing quality sound editing.

I's nice to see this kind of discussions taking place and since I've been thinking along those lines as well for quite a while now I thought I throw in my share. First I think the narrative approach is perfect for SP missions that you play once and be done with it. There a complex story-line and narrative cut-scenes really help to create an immersing atmosphere. The main problem I see with this is that when you play such a mission for the second time, you already know the story and watching the same cut-scenes all over again gets boring pretty fast. The second time you play such a mission it's not to know the story (because you already do) but for other things like trying a different tactics for example. The story steps into the background pretty fast there. To overcome this, a simple story-line isn't sufficient to keep the player interested but as suggested you need a whole story-tree. Now with a story-tree the replayability of such a mission is directly connected to the number of branches on every knot on the tree and especially on the knots earlier in the story. If you just have a few branches at the beginning, you'll replay the same beginning, over and over again, just to take a different branch further down and it'll still get boring. So to keep it interesting enough a quite complex tree with many branches is needed and if you really want to do those with cut-scenes and all, complexity gets out of hand pretty quickly even with just a few branches. In the end, I just don't think it merits the effort to create such a branching story if the player is unlikely so see most of the possible branches, just because it's too tiresome to do it all over again. For missions that should have a high replayability, this approach isn't really feasible I think. The other approach that was mentioned is to create a believable environment to play in and have the AI act reasonable within it. As some already mentioned, the first problem is that such an environment to be believable is quite complex to create. One possibility that was already brought up to keep the complexity down is to only concentrate on things that can be observed by the player and fake the rest. The major problem with this approach is that you need to be able to switch from a simulated environment to a real one, once the player is around to keep up the immersion. The actual action where the player takes part needs to result from the simulated action. For example, you could simulate the whole supply system with a script, but when the player decides that it would be a good idea to attack an enemy supply convoy, then you need to have real trucks driving somewhere. The same goes for pretty much everything. You don't have to have tons of AI units fighting a whole war, but you need to be able to switch between simulated war and real action. This can be a bit tricky for rather simple things like creating some trucks on a road that you only simulated before, but I think it can be done within reasonable effort. The other option is to not go for simulating a full scale war with hundreds of units, but to scale down the whole scenario to something manageable, like for example a limited spec ops campaign. For starting out, I think this approach is much more feasible as it doesn't require a huge amount of upfront scripting where you can loose yourself in details, as there are much more critical problems than switching from a simulated war to some real action. The main problem I have found is not the complexity as this can be scaled down quite nicely until it's not much of a problem anymore. But even with such a small scale scenario, the main problem is to get the AI react decently in a given environment. As noted, everything that's not right around the player is more or less background story and can be faked pretty well, but what the player notices instantly is when the AI he's directly interacting with is behaving in a non-realistic way. This can already be seen in current missions for OFP and ArmA and it gets even worse if you have to create it dynamically. In a regular mission you can just look at the map and place some waypoints for the AI, but as simple as this tasks looks like, it's quite hard to do this with a script in a reasonable way. First you have to give the script an idea about how the terrain looks like and how to interpret it. This isn't that trivial since there are no easy ways to get that done with simple scripting. You can do it by hand but then you either limit the whole dynamics right from the start by your selection of choke points, good places for a base, etc., or it gets a major effort to identify those terrain features and make them available to your script. Once you have that data it's rather easy to give the player the impression of the AI knowing what they do. Be it with with fancy things like NN or a simple planer that does all the things that you are describing. But the main problem is getting this data and interpreting it. If you can do that in an efficient and reliable way, then the rest is straight forward. So in my opinion the current discussion is trying to solve problems that already fail because of some more fundamental things. Even basic things like offensive or defensive moves are moot as long as the AI doesn't understand how to read the terrain in a tactical/strategic way.

Honestly I can't really see why you make such a fuss about that in every thread you can find. There are several videos out that clearly show that it's just not generally true what you're telling. Many people (myself included) can hit things pretty well with unguided missiles and cannon. Heck I even tried it myself with keyboard and mouse instead of using the joystick, just to see whether it's really that hard like some people claim. And guess what? It's not. It's even easier with mouse and keyboard. Now for the sake of it, if you have problems hitting something with the current flight model, then go do some practice instead of spending your time constantly complaining about things that aren't really much of an issue anymore. Thanks.

The thing that completely did it for me was to set all the sensitivity values to 1.00000. Before there were all kinds of dead-zones on the joystick even without any set dead-zones or axis-shaping in the joystick control panel for the Cougar. By setting it all to 1 all the dead-zones are gone and with some very little axis-shaping the level of control is just great now. (Flying with joystick, throttle and pedals.) The tail rotor could be a bit more effective at higher speed to just get the nose a bit left or right for aiming (not to change the flight-path), but with the precise control I get now it's workable to get the nose where I want even at higher speed. Thanks to everyone who was involved for making helicopters a joy to fly again! PS Even with mouse and keyboard the level of control is fine. You can land on a dime and get the nose everywhere for aiming rockets.Of course it's not as easy as in OFP where you could just screw around on the controls and get away with it. Now it needs a bit practice but it's all doable. Just get your head around how basic physics work and you'll see that it makes much more sense now than in OFP.

Yep, same here.

@CrashDome: I'm not trying to teach everyone how everything works, nor do I intend to tell anyone what he's supposed to do. I was merely explaining my point of view in something where it seemed that we didn't agree. The following posts were just to clear things up and I think we clarified what each others point is. That's all I intended to do Now back to the topic of functions and scripts. For OFP, I think using a function call would be the right thing to do, if the function is just doing what MrZig showed as an example for the function. Also using lots of such frequent function calls can give performance problems, because functions are run in one piece and either end or get aborted. Especially if the function does some more things this might become a problem. Also to me it looks like it's not the best way to design a function, but then we don't really know how the real one looks like. It's just that the sample code suggests that this could be done in a cleaner way (here's where patterns and practices come into play). Now for ArmA that might be different again. Especially after the findings about using the sleep command in functions. To me this suggests that scripts and functions are much closer in how they're run in ArmA than they were in OFP. At least for the new script type.

I think you guys are getting me a bit wrong here I'll explain what I mean by the example of the question that MrZig asked. He wanted to know which of the commented-out lines would be the best to use: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#lp ~0.01 ;call ZigPreprocessedCode ;[] execvm "ZigCode.sqf" ;[] exec "ZigCode.sqs" goto "lp Now having some insights into this topic, can you honestly give him a straight and short answer in form of rules, that is really true for what he's trying to do? I think I can't and here's why: If I tell him that using functions for everything is good coding practice and he goes on and implements 50 functions that may be a bit heavier than the example he posted and runs them every 0.001s, can he expect that to be working fine? The advice or the rule itself may have its merits but then he doesn't know in what cases it has merits and therefor can't use the rule for his benefit. To do that he needs to know the reasoning behind the rule. Now I tell him to use scripts as much as possible and he's running the same 50 scripts every 0.001s and doing a file access every time (or is that cached in ArmA*?). I doubt that he'll be happy with that rule either, at least as long as he doesn't know the reasoning behind it. What am I supposed to tell him? For some things there is just no straight and short answer that is generally true. That leaves me with basically three options: - Explain him how (according to my experience) the thing works under the hood and where he should look for traps so that he can go and not just apply it to his current problem but maybe for all the coming problems that he's going to face in that direction as well. - Tell him to just try for himself and see what happens because doing so would probably only take about 15 minutes and he'll get results that specifically match his problem and for sure is faster than me trying to explain the whole thing. At least this will solve his current problem and maybe even give him some insights to tackle the next one. - Tell him that it doesn't really matter and he should throw a dice to decide. For me that's the same as telling him to go by some kind of rule that might or might not apply to his specific case, after all I don't really know the details to judge myself if such a rule would be good to apply there or not. Also the time it takes to get the details (if he's even willing to share them) will probably take longer than the first two options above. And for rules or good practices, you say it yourself: What kind of language? ArmA scripting, C++, Haskel or even Assembler for some weird Motorola chip? You need to know the reasoning behind those rules and what they were geared for to be optimal to use them properly. In fact, it might even be better to write spaghetti code than applying coding practices from other languages/project types/plattforms/..., because the reasoning behind every rules is anything but universal. Hell, even naming all your variables x1, x2, x3... might be a good idea for some cases, so not even naming conventions are universal. The idea behind such rules is usually much more universal than the rule itself, but you don't teach someone the idea by just telling them the rule. For that you need to explain things. Rules are crutches for the brain to remember the reasons behind them, and you need them just because access to human memory banks is organized in such a weird way In the end every piece of code has its own set of things it needs to achieve and therefor you can't just apply general rules without knowing their reasoning. In most of the cases trying to get an average response time of 0.04s from a database is just wasting project resources while most time it's essential for a game. To stay with your example of the birds and the nest: If you just tell them that it's generally a good idea to flap with the wings, they might as well jump out of the nest thinking they can fly because they're flapping with their wings, only to crash into the next best thing since they didn't know anything about steering or landing. The result will be the same: Hurt bones. I'm not saying to just push them out, but to tell them what it takes to fly. After all they asked about it, so they should be prepared to get the full deal. After that they can still decide if they just want to sit in the nest and practice some flapping, but at least they know then what it takes to get it done. *are calls like loadFile, exec or execVM cached in ArmA? Somewhere Kegetys posted that tricks like fwatch don't work with ArmA. Maybe because file access is cached now?

I don't know why, but something like this seems to work for me when deriving vehicle turrets: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class cfgVehicles { class StaticWeapon; class M119 : StaticWeapon { Turrets; MainTurret; }; class MYM119 : M119 { displayName = "My M119"; class Turrets : Turrets { class MainTurret : MainTurret { weapons[] = {MYM119}; magazines[] = {"My30Rnd_105mmHE_M119"}; }; }; }; };

Dont forget that ArmA pbos have prefixes now. The line should read: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">model = "Ca\characters\civil_1_tshirt"; The name of the PBO is actually irrelevant if I got it right and only the prefix determines the path for the config. Since the prefix of the characters.pbo is "ca\characters", that's what should be used for paths inside configs to refer to models and textures inside that PBO. Same for the wound textures: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">mat[] = {"Ca\characters\data\civil_1_tshirt_shorts_klapky_ksiltka_hhl.rvmat","Ca\characters\*...*.rvmat"}; Also don't forget to set the required addons to what you're using in your config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredAddons[] = {"CACharacters"}; Not quite sure if that's all that's needed for the required addons, but it seems to work for me.

I still don't agree. A rule or good practices them self have no other value than reminding you about more complex things that are valid for a specific environment. Nothing more. Every other use of a rule or good practices is a bad use. You could as well throw a dice instead of using a certain rule or good practice. To know if your rule or good practice is applicable, you still have to know the complex reasoning behind it and the environment it is valid for. If you don't it isn't worth anything. So asking about rules is absolutely pointless. What people should ask for is explanations about how things are and draw their own conclusions. Question everything! If something is obvious, then it's easy and fast to explain and also to see that it really is. But by doing so you know for sure that things are that way and you're not just following a hollow rule. That's the most basic quality control you can and should do. Also when answering, I think it's also pointless to just state rules. For someone not knowing the things behind a rule, the rule itself has no value at all. So I'm at least trying to always give explanations instead of rules even if people get annoyed because it's getting too long winded abut things they don't even want to know because they think they can get away with more simple things [edit] Commenting on your edits CrashDome: My main point is that it's pointless following rules just because they apply for other cases. I don't think functions are useless at all. But there's absolutely no way in setting up easy rules that can tell you when exactly use a function or a script. What I mean is that you need to know the differences between the two and how this affects coding in various situations. This can't be taught by rules, this has to be learned by examples. There's no shortcut for that. My second point that results from the first is that games are different than "normal" programs since performance is the major factor. First you need to be concerned about performance, and then about everything else. So every rule or good practice you know from programming "normal" programs needs to be tested if it's still valid and if it doesn't put priority to something else instead. I couldn't live without good programming practices, but I always have to question whether something is applicable in the specific situation or not. Even programming practices for "normal" programs can be fundamentally different so that you have to decide which one you want to follow for a specific case. And with games it's even more tricky. So having good coding practices is nice, functions are nice, scripts are nice, know how they work and how they affect performance. Know how commands work and know how they affect performance. If you do that, you automatically get your own set of rules to make your life easier, but are worthless for others who don't know the rest (,yet maybe) [/edit]

Actually, I can't fully agree there. What you said is all valid for regular programming, but game programming is something different. For a game what makes or breaks it is how smooth it is running and that has pretty much top priority. If you have the best AI and the best looking graphics and all but it's running at 60 frames per minute, then you can throw it all away because it's useless. Now if a regular program has a response time of 10s it might be tolerable. And the case of choosing between a function or a script definitely affects performance, so regular coding practices can only applied after that is taken care of. Most of the coding that we do for OFP or ArmA doesn't rely on getting done between two frames and usually can take much longer without having any side-effects. For all cases where it's not necessary to have a fast execution time even on the expense of performance, I think scripts should be used instead of functions. In fact if your function is taking too long then it just gets canceled and you're off worse than with a script. In that case scripts are more reliable than functions. Also compared to regular programs with several million lines of codes, our OFP/ArmA scripts are tiny. If you loose oversight and get less reliable, portable and adaptable code because of using scripts instead of functions, then you're doing something else wrong. Scripts can be written just as portable, adaptable and reliable than functions. What matters is the difference in execution which makes an impact on performance. Following general programming practices without looking at how things work under the hood isn't a good thing. It's about knowing how to structure things in a given environment and adapting the rules to it instead of blindly following them. So know about good programming practices, know WHY they're good, know about the difference between scripts and functions (and not to forget the quirks and things about all the commands) and apply all this to get good running code that does useful things in the first place and is adaptable and portable and all those nice things second.

If there's no difference between civilian and regular soldiers in a mixed group, then you better check your install, because then it's definitely not working right. Put a mixed group of regular soldiers and civilians on the map with a soldier as group leader. Then give the group a normal move waypoint and after that another move waypoint where you set the group to "danger". Don't place any enemies. One thing you can sometimes see when they're running to the first waypoint is that the civilians keep a less strict formation than the soldiers do. But the main difference is when the group is set to "danger". The civilians don't kneel or go prone. One major difference is that civilians don't cover in a group while soldiers do. That's actually a bigger problem since soldiers look around in their group to see who's covering and if there aren't enough who cover they start covering. In a mixed group where there are more or equal the number of civilians than soldiers, this leads to a deadlock where all the soldiers are covering and waiting for the civilians to advance. But since the leader is a soldier and isn't moving since he's covering as well, they don't move. So the group gets completely stuck. Also civilians are set to do all kinds of things like run for cover when the shooting starts. The difference in movement behavior is triggered by setting the group to "danger" and the fleeing and other stuff is triggered by the AI itself when it feels it is in danger due to shooting or sighting an enemy. If you know a little bit of scripting, then have a look at the .fsm files in the characters.pbo. The formationC.fsm and the formationCDanger.fsm are the fsms the civilians use while the formation.fsm seems to be the scripting equivalent of what the regular soldiers use (although they seem to use a hardcoded version of it).

If you need a return from a script then you can also give it an array as parameter where the script puts the result(s) in. Since the array is given to the script by reference, you can read out the return values afterwards. Something like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_resultArray = [0,""]; _handle = [_resultArray] execVM "resultScript.sqf"; // script runs and changes the _resultArray that is was given waitUntil {scriptDone _handle}; _resultInt = _resultArray select 0; _resultString = _resultArray select 1;

The doFSM and commandFSM commands them self do work, but somehow the formation.fsm crashes the game when used with those. But since those commands don't "override" the config-defined FSMs, but run side by side with them, you probably wouldn't have much joy because they would constantly get into each others way. Also FSMs run with doFSM or commandFSM seem to be exited instantly when any another command is given to the unit, so there is no guarantee how long your FSM would run.