crashdome

I agree. There doesn't seem to be any other way. I myself have created a system which is like you described. It loops and checks various conditions. I think of it as my own custom eventhandler system. It would be nice to have like an FSM controller API whereby you could query the current executing FSM similar to how we can check "CombatMode". I am not sure if that is possible, but I really hope the right people are listening nudge-nudge wink-wink. As far as non-terminating FSMs, I have learned to work around them. I also have begun to think they are more trouble if they last that long.

All I got out of all that is that you wish the FSMs worked in a way that they don't. I can say I sympathize and actually wished they were something else also, but the reality is they, like functions, are special purpose tools. Thats all I am trying to help you with. You said you are considering going back to SQF and I think that is the better choice... then you lay out reasons why you can't. You also say scripts are more resource hungry but I cannot find out how you arrived at that conclusion. I guess I am the one who is confused.. When a unit enters or exits a vehicle some strange things go on I've never put my finger on. Some people may have figured it out, but I ended up not caring so much to dive deeper. FSMs are group level I think.. not unit level. In OFP, you can see weird effects by joining units inside a vehicle with another unit outside a vehicle or vice-versa. I see the "effectiveCommander" command is new and having never actually used it I cannot comment on its purpose, but I am *guessing* that an FSm terminates when a unit gets in or gets out because the unit has to undergo some sort of command restructuring.

@5133p39 I know it sounds really frustrating because you want to have a single FSM control the unit throughout the whole game (atleast as much as possible). However, I came to a different understanding after I completed a number of the same tests (btw an FSM can be run while a unit is a driver - the change of effectiveLeader probably has something to do with the FSM termination?) I learned that an FSM is not meant to be run throughout the whole game and is for *temporary* behavior use only. I've been in almost every FSM thread here and the end result of why people get frustrated is because they wish to control the overall behavior of AI. FSMs cannot do that here. What you really need to do is work with waypoints for controlling the unit moving from city to city... or to perform a task (i.e. run to the market). That is what they are there for. Why use a tool for controlling detail to control overall when you have tools for controlling overall (waypoints and scripts). If you need to control behavior such as how a unit finds a vehicle, or when the unit needs to get around a roadblock, etc.. THAT is what FSMs are for. So, go back to an SQF script, and use it to plot your waypoints to move units around the island. If you got units you want to make it appear to walk between shops and go window shopping.... use an FSM.

My tests showed the same results. I could not for any known reason order a unit into a vehicle. The *only* way I can see this changed is by doing what you did. You might try adding an eventhandler onto the vehicle before you order him in. Upon entry, the eventhandler should execute the FSM again once the unit is "in" the vehicle and remove the handler. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (unit in vehicle) then ...

You are fighting what is considered standard and acceptable behavior by the AI. There is a leader, he orders the RTF because that is where he wants his units. CommandMove was not introduced to do this behavior. It is temporary "group level" behavior control which institutes a temporary movement order. If you want the two 'sets' units to behave independantly, I recommend splitting the group up and joining in the end or creating an FSM to control formation. FSMs provide more low level behavior and provide exactly what you need. You can find more info here: http://www.sinewsofwar.com/Downloads/Tutorials/tabid/254/Default.aspx

movingEnable lets the player move when the dialog is displayed, not makes it movable. Hmmm.. are you sure about that? I've never seen a player able to move with a dialog up. I assumed it's because all controls (keys) get passed to the dialog instead of player control.

Hmmm.. I assumed that picked which unit was to be leader, like you could "select #5 to be the leader" but it wouldn't switch them to the #1 slot. His problem was that he was already leader but that he was in #3 slot instead of #1. I will check to see if that does anything. @Taurus OK, I understand where you are coming from a bit better. What you want to do is copy my script above into your folder and rewrite your script such that when the player calls it (to join new units). you have this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[player] call compile preprocessfile "regroupScript.sqf"; "SoldierWSaboteur" createUnit [getPos _respawnPos, group player,"doStop this",0.5, "private"]; "SoldierWSaboteur" createUnit [getPos _respawnPos, group player,"doStop this",0.5, "private"]; and you should be fine. Oh, and don't run this on the server if at all possible.

yeah.. add it to a vehicle... not a player

@Taurus I hate to say this and I mean this in the most lightest sense so please do not take it personally: Your code is mostly redundant. For one, you reference the leader for no real reason other than to join him first???. You create two units for reasons you never stated. You also have sleeps every 2 seconds for reasons unknown and what would appear to be every other line of code. You join each unit in your group to a new group individually when join can take all units at once no problem. Finally you want to check conditionally the size of the group so you can assign it to a private variable at the end of a script??? I guess I am lost to your goals? I thought you wanted to become #1 if you are the leader of the group in some other slot? Won't joining a new temporary group and then back to the old one accomplish that like the script I suggested? @ColSanders You raise an excellent point. In terms of AI (even with player as leader), it is a function so you would only want to call it at a point you knew was safe to do so (from a parent script). For another, you can find out if combat is occuring by checking the state of the leader if his assignedTarget is not nil. [Remember this thread ]. Once you determine it is safe you could very easily call it. I foresee another problem though.. mostly with scripted behavior mods and FSMs. Anything running will probably fail because of the group switch (but I am not positive). Although you can also check for those if desired. If all the units are players it really isn't needed anyways. And I still dont know if my script works I don't have a ded server set up yet so I can do any real MP testing. In a hosted MP session it worked flawlessly... there was a typo which I fixed above. Here is how I called it: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[player] call compile preprocessfile "regroupUnits.sqf"; After calling this... you can add any newly spawned units to the group and they are appended to the end.

You can hide an entire section of a dialog and call it into display at any point. Likewise, I think it is possible to even have say ... three different sets of controls in the same location and based on what you do you can hide/show them via a single custom function. They would all be layered on top of each other is all were visible, but if you can control their visibility, it would appear as a seperate dialog. ctrlShow for modularity, use includes and inheritance

I remember this problem in OFP... no real way to rearrange units. For the most part, the beginning order is usually set by rank. When you spawn into #3 you are lower in rank. As you add units they take up empty slots #1 and #2 even though they are lower rank. IMO, as units die, the # should change rather than keeping an empty slot (i.e. it's a stack where units move up in order as leaders are taken out). All the other games do it... and there is certainly no way to reference a "slot" via scripting so really it is a bad idea the way they have implemented it (for asthetic reasons). The only way is to disband and rejoin. We DO have the new "joinSilent" command so the annoyances of doing it this way are reduced. In fact if we make this a function, we could introduce our own implementation via the killed event handler and it would be virtually instantaneous.. hmmmm.... *goes away to code stuff* OK back... Can someone test this (I'm not at home) and maybe add anything they can think of? It can be called on any unit (leader or not) and should reorder the group. The idea is to call on the player OR add to a killed event handler for each unit in the players group. I don;t know what the sideeffects are but I can imagine there will be some. I also added an error msg in the event there are already too many groups. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//////////////////////////////////////////////////////////////////////////////// /// <header> /// This SQF Function created using Script Edit v0.8 on 2007-06-20 13:39:28Z /// /// <author>CrashDome</author> /// <filename>regroupUnits.sqf</filename> /// <version>0.5.0</version> /// /// <summary> /// This function, when called on a unit, will disband the group and rejoin (silently) to reorder the command structure and the appropriate unit number. /// </summary> /// /// <parameters> /// <param name="unit" type="Object"> A unit of the group to restructure </param> /// </parameters> /// /// <returns>Nothing</returns> /// </header> //////////////////////////////////////////////////////////////////////////////// //REGION INIT PARAMETERS private ["_unit"]; _unit = _this select 0; //ENDREGION try {    private ["_group","_newGroup","_unitArray"];    _unitArray = units _unit;    _group = group _unit;    //Creating new dummy group instead of using "grpNull"    //in the event there are already max groups we can    //capture the error    _newGroup = createGroup side _unit;     if ((isNull _group)||(isNull _newGroup)) then {throw "NullGroupException";};    _unitArray joinSilent _newGroup;    _unitArray joinSilent _group; } catch {    if (_exception == "NullGroupException") then    {       player sideChat "regroupUnits.sqf: NullGroupException";    }; }; [Edited Code June 21st, 2007 - small typo]

Use the Killed event handler and attach it locally to the player. It should run a script which "reads" the values of what the unit is carrying. You then use the waitUntil command and check the health for when "player damage > 0.5" or something and then reapply the weapons. I would write it all out, but I am limited on time and I am sure someone has one already...

I answered your ? at OFPEC which might give you headway, but I'll reiterate here in a diff way: Try using your FSM to create a waypoint structure rather than controlling all movement at all times. I found you can create a whole series of waypoints that the AI will promptly follow once you kill you FSM. Now, I believe that some waypoints you can even attach another FSM using setWaypointStatements command. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[grp,2] setWaypointStatements ["true", "grp doFSM ""MyFSM.fsm"";"] i.e. when the above waypoint is reached (and set 'true' by waypoint condition) the FSM will engage. I have not tested this myself, but might provide you insight. My whole point is to - instead of disregarding waypoints and trying to control everything yourself - use the FSMs as a tool to make the AI behave and create/use the waypoints properly. Also, setDestination I think is more for formation behavior and things like flanking/combat maneuvars because you need to set it for each individual unit.

@5133p39 You are absolutely correct. You wouldn't want the headache with trying to run multiple FSMs. Also, there is some behavior changes in regards to coding with FSMs and these are not scripts which can be run in parallel and loop consistantly. It is not the purpose. @whisper FSMs can be run on client PCs. Remember that your group of AI units are local to you. Do NOT use doMove or move in an FSM. The reason they are not moving is because Move creates a waypoint and all waypoint following is suspended in an FSM while doMove will instantly terminate your FSM. Use moveTo or setDestination.

Hello everyone. If you were looking for an editor for Armed Assault, I encourage you to take a look at my latest release. I have received alot of feedback from closed alpha and beta testers. We hope you enjoy it. Documentation is included in the install, but is not completely comprehensive. There is a good portion which is WIP. Feel free to post questions here or on the JadeGear forums. latter is preferred Website Notes I would like to make: This is a beta version. On my website you will see a list of features. This list is for the FINAL version and the beta may not contain all the features listed - and the list may change. This product is for non-commercial use only

Did I ever once mention or imply that in my post? I mentioned CoC_NS because that is how I accomplished it in OFP and I mentioned it was my preferred method because it reduces code. I did not say it was currently possible - nor did I say it wasn't. Any other statements, infered or otherwise, I will not held responsible for.

I will tell you right now it won't be easy. Someone may come along and suggest a method, but in truth there is often limitations or problems with most implementations. I suggest you look into some of the CTI missions and see how it is done. Personally, I prefer the client request method. It works best with CoC's Network Services scripts as the code becomes a single script/functions and a few lines here and there everytime you request money. The way it works is simple: On the server exists all monitary information (array or otherwise). There is also a single function which requests/deposits money into the arrays and handles validation (i.e. does player have enough? if no, send error. etc...) Everytime the client performs some action which requires money, you simply request/deposit by calling the function server-side and simply providing the values. This is where CoC NS is a huge help. On the client side it can be one function call - without NS, you need to PV a bunch of data back and forth manually. The return result should say whether or not you have enough money or what your balance is. This is the best because it completely ignores actions and such and allows you to mod very easily by implementing your own methods of buying/selling stuff.

It is always an assumption that one versus many is going to be better when you cannot compile before hand. This is assuming it needs to compile or read the file each call. What type of difference this makes is not known. Don't thank me! I didn't write it

Have you read the tutorial? Tutorial You may find some of your answers there.

Last year this time, we at SoW tried out a "Mission of the Month" program for OFP whereby anyone could submit a *simple* mission based on one of two themes that were suggested. The whole goal was to increase activity in mission making and progress learning for the new people by giving them simple missions to work from or tweak. It went over really well and we had alot of support, but interest faded quickly as mission making in OFP faded in general. We are thinking about instituting it again and even making it available to the general public (no user registration required). Here is what happens: Every month, we pick two themes with a basic tactical or strategic premise (e.g. "Hasty Ambush"). A few minor requirements or rules to keep the mission on track are listed but general freedom is encouraged. We accept submissions over the course of that month and allow them for download by everyone. There are no prizes or contests. It provides an open environment for new guys and old alike to actively try their hand at mission making without the added pressure of everything being required (briefing, cutscenes, etc..) for submission. We understand there will be bugs and objectives simple, but that is the point: to allow others to take something and learn from or expand upon! This type of program survives only based on the content provided, so we would need to have some people actually making missions for it to be successful. Because of this, I am looking for feedback from some of you Mission Makers out there to see if you are interested in helping out the new guys and building a few *simple* missions?

[EDIT] Nvrmind.. realized you still cannot TAB to unit

OK, maybe a user rating system w/ comments? Instead of mission contest with ranked winners... how about the regular 5 star rating system? This way you can have several 4-5 star missions?

Also, just because it is one command doesn't mean it is one operation. You are executing the same number regardless.

As a followup... Am I barking up the wrong tree? Is everyone saying they will submit missions only if this is a contest? ...because I can certainly make it that. I just figured I would get more content be making it more flexible and less stringent.

I am not saying a mission has to be crap to be submitted. I am just saying this is NOT an OFPEC Mission depot where you submit you missions for review or ranking. It is a place to put a mission which may perform a certain task. The idea is that some new mission maker may one day WANT to make a really good mission and needs something to start from... or perhaps they really liked the way the AI reacted in one of these simple missions and wish to see how it was done. I don't know how many times I must reiterate that this is not a contest!! Your mission will not be reviewed. Your mission will not be ranked. Your mission will not be judged. Highly polished is certainly a wonderful thing, but that is not the idea. The idea is that you might read one of the themes and decide you want to make a brief mission that resembles these ideas. You maybe do not want to write a cutscene or briefing. Maybe you just want to show people a way to perform some task in mission making. Maybe you want them to have a really good mission! It doesn't matter. Think of it like a library. Some books are short stories or poems and some are full length novels.