Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Everything posted by crashdome

  1. crashdome

    Thinking about Mission of the Month again

    Read the first post people!! I could see a mission which had AI on both sides yet all were playable (in case you wanted to switch sides or fill with all human) but certainly that is up to the mission maker I suppose. I am not against anyone making any specific type of mission. The only rules are usually that the mission be about the topic specified. Whether you can muster an adversarial MP mission out of it is certainly up to you!
  2. crashdome

    Thinking about Mission of the Month again

    Perhaps we've already done this before? If you reread what our goal is, you will see that we are not looking for highly-polished and complex missions. Last time we tried this, we had no problem creating several missions in a one month period of time. In fact, we had most people *waiting* for the next month's themes.
  3. crashdome

    Thinking about Mission of the Month again

    Hmm.. how about instead of two themes per month.. maybe one theme twice a month (1st and 15th of every month)? ...but submission is available for a duration of one month? ....or would two themes at beginning of month be enough to hold everyone over for the entire month? [EDIT] Now that I think about it... one month may be long, but you will need a break to play all the new submissions! So, two themes per every 1st of the month it is!
  4. I would like to note that Rune has also informed me that the KPCTI by granq had an FSM within the mission. I had a look and I think it is a prime example of what the purpose of an FSM in ArmA was expected to be (by the developers). This particular FSM is something run on the Engineers to perform the mine clearing. Whether or not it is used or who was the exact author (I am assuming granq), I am not sure. It is a good example though.
  5. which was similar to the snippet I wrote and then scratched out  because mine was wrong. You would use this line as your condition in an if statement or trigger etc.: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if ({_Y = _X;{_X distance _Y < 100} count (units GroupB) > 0} count (units GroupA) > 0) then {hint "We are screwed!"}; How long have we been able to use _Y? Where was that documented? How deep can we go? _Z?
  6. crashdome


    You are about 4 years too late. The myth is he was so consumed by OFP and scripting that the video game gods sent their worst creations to battle him. He managed to beat them all by performing elaborate airstrikes and countering their intelligent group connections. The battle was so intense he literally BECAME code. Some say that SQF Functions are the reincarnation of him, but others say they see him chasing through the woods of Malden and dark and stormy nights. Personally, I think BIS hired Mongolian mercenaries to capture him and had him extradited so they could tap his brain waves.
  7. crashdome

    Hiring Soldiers

    Put this in the activation line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"SoldierWB" createUnit [getMarkerPos "Respawn_West", group player]
  8. Use a JOIN waypoint and syncronize it to the other unit's waypoint.
  9. crashdome


    What does this mean? Is that suggesting community made content or just the addons incorporated into the different distros?
  10. crashdome

    Meet the Bear

    hehe ... yeah... right.
  11. crashdome

    Meet the Bear

    Ummm.. why not have the robots do the battling in the first place
  12. I had a great idea and it went south as soon as I realized that even though we have the ability to assign/unassign and dissolve the Team colors, we have no ability to retrieve what units are IN a color group. Or am I missing something obvious? [EDIT] I will go one further and say that it would be nice to also have the ability to determine units from what the player has selected. Currently, only OnmapSingleClick has this ability. It would be nice to say, call an FSM and pass in the selected units OR somehow determine if the are selected ("IsSelected" maybe?) on the current client machine. Granted this has limited scope (only player led teams AND local to client) but the usefulness is as extreme as OnMapSingleClick.
  13. crashdome

    Getting the group leader

    just try this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">alive leader vehicle this
  14. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_a = 0 #SeverlyLimitedAndPerformanceKillingBecauseIWontLearnSQFLoop _unit = GroupA select _a ?({(_x distance _unit)<100} count units GroupB > 0):goto "FoundOne" _a = _a + 1 ?(_a < count units GroupA):goto "SeverlyLimitedAndPerformanceKillingBecauseIWontLearnSQFLoop" ;Didn't find any exit #FoundOne ;Do Something exit
  15. crashdome

    FSM-Users here?

    OK, I am glad we are really on same page. Native FSMs we have *nothing* on. The document and our testing has been on focused research of the scripted FSMs because we believe that is the first area the scripting community will tread. Native FSMs, we believe, are similar in concept but will only be useful in addons which might have complex features that the regular FSM will result in odd behavior. Therefore, you can tweak using some low-level *but severely limited* properties to get your *feature or idea* to work properly without scripting some elaborate workaround. Again, these are assumptions and not based on actually creating any for testing.
  16. crashdome

    FSM-Users here?

    Low level access to all properties would render the engine unstable and in reality break almost everything. Â Then you haven't read enough of my posts. Check native FSMs.. and also, what you are asking is not an interface. You want to recreate the engine. You are asking if you can simply dump the AI and make it yourself. You might as well ask if we can dump the 3D engine and make our own. You will probably reply "thats not what I am asking.." but in reality .. yes.. you are. See my reply above... same reason. You are asking to override properties of units and make your own AI engine. I don't think BIS will *ever* allow the community to do that. Secondly, the advantages of FSMs (when understood) are really powerful. You can look at it as "parallel scripting", but IMO it is truly an interface to the AI. And by interface I mean a true interface where you set values for properties which are publicly exposed and the AI engine responds in kind.
  17. crashdome

    FSM-Users here?

    I am stepping out of bounds a bit here... but there has been a considerable effort by a fellow SoW member in determining the finer points of FSMs. We have a considerable amount of documentation completed (25+ pages). It is not released yet, but answers alot of questions. If you are going to ask why it is not released, all I can say is "because we are putting final touches to it." I can specifically summarize that FSMs are not unreliable when used correctly. They are also not the end-all be-all answer to changing the AI behavior. Typically they are used for scripted behavior (like scripts), but there are advantages over regular scripts. The ability to perform another *small* action and then return to the FSM without any elaborate checks is one (i.e. reloading, grabbing weapons - a script would need to 'wait until unit is ready' whereas the FSM doesn't need to wait at all). The ability to terminate an FSM by ordering the unit to do otherwise is another (a regular script would need to loop constantly if you wanted to terminate it 'at any moment when unit is given an order to do something else' ) Native FSMs I have not dove into yet because the scripted ones are so difficult to comprehend (without proper documentation by BIS Â ) that it took some major testing to find the limits. We make some assumptions about native FSMs, but nothing concrete enough to say "this is how it works". [EDIT] These statements are false. Suggesting that because "scripted FSMs" are subject to the same commands a regular script is subject to doesn't make them able to access the AI is a total anti-thesis. Rather, FSMs have considerable access to AI behavior, but so do scripts. The real benefit to FSMs is more evident when you try to stack an FSM which accomplishes a task (according to the intention of FSMs) against an SQF file version of the same task. You will find the SQF fails miserably in terms of reliability and performance in most cases.
  18. The easiest method is to create a trigger with the condition: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">alive player and set it to repeatedly In the activation of the trigger, have it run the script to populate the actions. Everytime the player respawns, it should run. Atleast, that is how I remember doing it in OFP. [EDIT] Note: this applies to ALL players. Meaning all players wil have same actions. Not sure if you want that...
  19. crashdome

    Software Archaeology

    That doesn't necessarily mean they won't. I am betting there is far more information in the originals in the form of textures and slight flaws which tell stories themselves sometimes. Hard to get off a copy in digital format.. BUT the topic was about storing "digital history" not storing "history digitally"! i.e. the original is already digital. Also, does it matter if a CD-ROM can last a century when at the click of a button you can transfer to other digital media without loss of information?
  20. crashdome

    Group engaged?

    no no no.. not empty hind... a non threatening (i.e. pilot w/ no gunner) vehicle. You are taking my tests out of context. My goal is as I stated above. I want to execute a script *only* when a unit is engaging another unit. NOT when he simply knows about them.. NOT when they are simply near them... and NOT just because they are enemies. I ran another test and removing weapons from a friendly unit and watching his assigned target (never changed) in the presence of enemies.... it is like I thought. ONLY when the unit CAN engage an enemy (i.e. he has a weapon capable of damaging the unit) does he get assigned a target. So a rifleman will never have a T72 as an assigned target - even if they are threatening him . This is what makes it more useful to me. It would seem the AI leader will do the assignment, but as long as a player is not the leader, he will have an assigned target before engaging (this includes running to and using grenades and such). IF the player IS the leader... then assigned target doesn't really work but my script is only for AI leaders anyways. In theory, I could use assignedTarget alone for my purpose... but I think the other commands provide better context of the situation. As beneficial as it is, assigned target fails when it comes to simply checking for units on the defensive (i.e. being shot at) because the T72 can be shelling a unit and his assigned target might be nil because he has no rockets. That is where findNearestEnemy comes in handy. However, I am wondering if nearTargets would be better because it shows threat 'value'. I just don't know what it means by "more important of a target". Is a T72 important if the unit is a rifleman? (Just tested... appears it is) To sum up, this is not necessarily about a specific target or group of targets. I simply want to know if a unit is engaged in battle. Behavior is a big help but too broad. AssignedTarget is the best, but fails when a unit cannot fight back (this can also be a benefit as in my case where I want to filter out defensive/retreating engagements). The best to wrap it up is either nearTargets and/or findNearestEnemy to conclude the context of the situation and determine if it is a defensive/retreating engagement.
  21. Does anyone have a solid and reliable method of determining if a group (or the leader) is engaged in combat? i am not looking for if they "fired' or if they are "prone". There is a point in which a group walking safely along the road has seen enemy units and draws their weapon. Does the Combat Mode change accordingly? What if a group is already in "combat mode" via script? I guess what I am asking is: Has someone found a reliable method of finding out that moment a group discovers an enemy and stops following their waypoint (without large overhead of scanning every unit)?
  22. crashdome

    Group engaged?

    Just tested.... excellent find! (How did I miss that one?) At first appearance, it would seem it has same effect as findNearestEnemy. It doesn't. A unit will engage another unit and assignedtarget will appear to return a result *unless* the unit CANNOT engage it. For example, the MI-17 was a result for findNearest.. but not for assignedTarget. This would leave us to believe we could replace findNearest... with assignedTarget but I am thinking that in times of danger.. using both would be beneficial. For example: [*]IF behavior = COMBAT or STEALTH : Â Moving with aggressive/defensive intent [*]AND findNearestEnemy count > 0 : Danger!! (perhaps run away? observe activity?) [*]AND assignedTarget not null : Engaging a unit!!
  23. crashdome

    Group engaged?

    OK... I performed my tests and came to a reasonable solution. Being the good statistics student, I tested for the null hypothesis by testing all three dependant variables (Behavior Mode, FindNearestEnemy, and CurrentCommand). Preface: I found it unusual that simply placing an enemy Camel aircraft overhead causes a unit to immediately go prone and follow the aircraft as if engagign it, but then I gave it second thought and figured that exactly the behavior that should happen. The unit should perform a type of recon or observation in a "this could be dangerous" state. IMO, this is NOT engaging the enemy, **however** observation can be construed as a form of engagement in some circumstances. Conclusion: findNearestEnemy Works well, except that even in a unit in a careless state a known enemy will be returned (not engaging because "careless"). Since this generates a false positive, I tested no further. behavior Exactly as Gen barron described. Combat and Stealth ensure that engagement will happen. Unfortunately, setting a unit to these modes even though there are no enemies generates a fals positive. Tested no further. currentCommand Empty the whole test. Only when I forced a unit to attack by targetting a unit and telling them to "Attack" did it return a value. Opposite of false positive, but still fails to capture all conditions. Not significant. behavior + findNearestEnemy So far this is the best method. Assuming a careless state, even though FNE(findNearestEnemy) might return a value we can conclude that *only* in the situation where: [*]Behavior = COMBAT or STEALTH [*]findNearestEnemy count > 0 do we have engagement... Note: The non-threatening aircraft such as an empty MI-17 will generate engagement in this formula, BUT if we can combine with perhaps nearTargets or some other method of threat detection we can get more accurate results of whether or not the units will actually fire on the other unit given the chance. CurrentCommand could be used, but I had instances of firing without any result from currentCommand registering. I am going to fiddle with nearTarget by taking the array from findNearestenemy and comparing the threat values. I want to see what type of threat values are returned and how they stack up to different types... i.e. is a SU-34 more threatening to another aircraft versus a ground soldier. [EDIT] btw.. findNearestEnemy always generates actual object - it does not ever generate an "unknown".
  24. crashdome

    Group engaged?

    @General Barron Excellent idea! but as you can see I am concerned about the stealth mode in particular. If AI units are in stealth mode, I cannot determine if they engaged in combat, HOWEVER, it is by far the best option right now. I could perhaps resolve my thinking that even though a group is in "Stealth" movement they are "engaged"... but the question is then "with whom?" @ColSandersLite Also excellent idea but with one flaw... if the units are not engaged with a known enemy, it will return a false positive... examples: Patrolling units perceive an A-10 fly overhead. UH-60 sees a convoy of trucks on the road enroute to waypoint. At a brief moment it could return a positive, even though none of the units are likely to engage. I could add additional checks, like combine it with Gen Barron's idea... hmm.. maybe it has merit but only in combo with other commands. @Everyone who posted Excellent discussion so far! I hope to resolve this seemingly simple concept.
  25. crashdome

    Group engaged?

    Hmm... countEnemy is of no use as you need to supply an array of units, but findNearestEnemy has potential. Are you saying that findNearestEnemy is always null when they are not engaged? What about aircraft? This is an interesting command by itself, I wonder about the limits and potential. On the other hand, I was always thinking of nearTargets. The problem is that it requires a distance. I really don't want to be concerned about distances, arrays of units, or threshold values. What I would like is simply to know when a unit has departed from a waypoint/actions as a result of combat/survival. Simple true/false equation. I realize I am asking something and putting in severe limits as to options, but there is good reason: I want to execute something *only* when a unit is in combat. Whether it is aggressive or defensive... whether it is man or vehicle.... etc.. etc.. I dont care. I will find that information out once I execute, but my dilemma is figuring out *when* to execute. I impose limits in that I want it to be a simple check - no fancy loops or triggers or having to store arrays of units. One single function call every brief couple of seconds called on an AI leader unit or the 'group'. That is my goal! I encourage wild ideas but no elaborate work-arounds using some voodoo method that isn't guaranteed to work 99.9% of the time [edit] I saw this after I posted... Yes! this is similar to what I am looking for, but I am not sure it is good. For one, there were some indications of when the current command was "NoPlan" or whatever. I wasn't sure if this is because they are not engaged or simply that they haven't been given their next target. What I mean to say is... does "ATTACK" hold true for all units engaged at every moment of the engagement? I must test this when i get home