MadMonk

Thanks for the dog script it works great! Its cleared up a couple of misunderstandings I had about FSM's. It looks like the create agent method is broken when using doMove, Ive verified this a number of times now and have converted to using createUnit instead. It would be interesting to know the difference as I get the imrpression that createAgent has less overhead.

Thanks for this, Im going to have to look into it further. Actually, when I say dog, I'm actually using a man for the time being since creating a dog from the animals2 pbo using the createAgent method throws a repeated error log in the rpt file that just continues indefinitely. This is the error in case it means anything to anyone. I am thinking that its a conflict somewhere with an underlying fsm for the dog. The following three messages are logged repeatedly -: It seems that the createAgent command is causing problems with Arma 3. With further testing, I proved that doMove does work in the fsm if I add a unit in the editor and call the script in the units init to run the fsm file, whereas using createAgent and doMove, the unit remains static. To note, with createAgent and setpos, this does work. I seem to remember reading something a while back about createAgent not having any underlying AI functionality and that a doMove doesnt work because the base AI isnt there, I could be wrong though. Next step is to test createAgent and doMove with Arma2. The reason I'm caught up on using the createAgent method is that I've seen it being used in the Dayz code and thought the technique could be applied to dogs. Maybe not, or maybe its an arma 3 quirk. Basically I want lots of dogs that can run in packs and Im hoping to implement a fairly in-depth AI system. ---------- Post added at 20:51 ---------- Previous post was at 20:37 ---------- Many thanks for this, I'll give it a try and let you know how it goes. Yes, I'm hoping for some badass dogs with arma 3, the arma 2 dogs are pretty tame looking but I found that sampling some decent barking sounds off youtube clips does give them an edge. Its a shame the attack animation isnt configured though, I spent a good while looking at it, learned a fair bit but didnt crack it in the end.

Thanks for the replies. Ive tried reproducing the FSM in arma 2 and it still doesnt work so it looks like its a problem with my understanding of FSM's. At the moment, I'm experimenting with an example I found at this link : http://resources.bisimulations.com/wiki/File:FSM_Demo.zip I've got the example working, with a little tweaking as it was written for the BIS simulator system. Once I'm happy I understand what I did wrong, I'll convert it to Arma 3 and post my findings. Btw Zapat, I took the dogs from arma 2 by adding the animals2 pbo file. They work pretty well when controlling the dogs by script but I know FSM is the way forward now Ive been reading up on them. The animals 2 pbo dog (Pastor) does have some references missing to certain animations (like attack) which is a shame, Im hoping to be able to fix this by extending the config and adding the references to the rtm files. I have tried this once but didnt have any joy, but Im definitely giving it another go once I crack this FSM.

Ive been trying to convert some sqf script for a dog AI system into an FSM now I understand how they work, but I'm really struggling with moving the dog unit around from within the FSM its self. As I understand it, if the FSM is called using the execFSM, any agent moves must be done using doMove. If the FSM is called using doFSM, then moveTo should be used. Having looked at some existing FSM code in arma2, I have seen examples that disprove this observation and I'm thinking that something could have changed with a patch. I've tried both calling methods in my code and the unit doesnt move at all. Ive put some over the top logging on all scripts and stages in the FSM and everything seems to be ok but no movement and no errors are logged in the rpt file. Up to now, the only Arma 3 FSM's Ive seen do not contain any functionality to move units and any information about moving units relates to Arma 2 and before. In case anyone else is looking at FSM's and finds this post in the future, Im posting a link to another thread I found which contains some good info but it doesnt seem to apply to Arma3. http://forums.bistudio.com/showthread.php?118451-doFSM-or-execFSM-is-there-an-advantage-for-one-over-the-other

Ive been trying out the say3D command, this seems to work perfectly. If anyones trying it, just pop the references to the sounds in the description.ext and play the sound on a trigger such as -: rabbitDog say3D "growlSolo"; rabbitDog is a unit class CfgSounds { // List of sounds (.ogg files without the .ogg extension) sounds[] = {growlSolo,growlZevon}; // Definition for each sound class growlSolo { name = "growlSolo"; // Name for mission editor sound[] = {\sounds\SoloGrowling.ogg, 1, 1.0}; titles[] = {}; }; class growlZevon { name = "growlZevon"; // Name for mission editor sound[] = {\sounds\Zevongrowling.ogg, 1, 1.0}; titles[] = {}; }; };

Just a note to correct the first playsound3D script example above, where I said that this works, what I meant was that it played the sound correctly but had no positional characteristics which I suppose would be correct since the location is the player. I've been looking into this command but the only info I can find is on the BIS wiki page. What I'm hoping to do is to add some shouting and dog barking sounds to a mission but for them to be really authentic, the positional effect is key.

I've been testing this arma 3 command out tonight but I cant seem to get any positional properties to the sound. Changing parameters, I can adjust frequency and volume but not the position. I wonder if this works only with 5.1 systems and not with two speakers. Syntax: playSound3D [filename, source, isInside, position, volume, frequency, distance] Parameters: [filename, source, isInside, position, volume, frequency, distance]: Array filename: String source: Object isInside: Boolean position: Position volume: Number frequency: Number distance: Number - How far is sound audible (0 = no max distance). playSound3D ["C:\Users\A\Documents\Arma 3 Alpha\missions\playsound.Stratis\Zevongrowling.wav", player] This works playSound3D ["C:\Users\A\Documents\Arma 3 Alpha\missions\playsound.Stratis\Zevongrowling.wav", dogs, false, getPos dogs, 1, 1, 0] dogs is another unit (actually a rabbit that I have named dogs) that i move around the player to test positional properties. last value (max distance, 0 = no max, any other value here and there's no sound) last but one, volume (anything over 1 doesnt work, 0.1 lowers volume considerably) frequency alters pitch of the sound correctly. I am not sure what the difference is between source and position parameters. Source must be an object or unit, so in the test I used a rabbit. Does this mean the source of the sound, if so, then what is the position parameter.

Thanks for the replies, It seems to work now with the original line of code for the unit initialization with nothing different. I did have an arma crash to desktop though just after windows telling me I was nearly out of memory (4.7 gig used out of 8 gig) so there might be a memory leak somewhere. Next step is to equip some AI with flashlights.

Thanks for the suggestion, it didnt work here. Is the headlight control the right action, Ive gone through the controls and it seems to be the obvious choice.

I have placed this script in the player unit initialisation to add a weapons mounted light. The item appears in the inventory and is attached to the weapon but I cant switch it on. I have tried the headlight control L by default but it has no effect. Does anyone have any ideas? this addPrimaryWeaponItem "acc_flashlight";

I always assumed that rendering high detail terrain from a distance was too much of an overhead for the engine. A while back, me and a friend did some testing to determine the visibility of a player to someone at distance when the player being observed is crouched in grass and thinks they are fully camoflaged. The results were pretty bad really, the player basically stuck out like a sore thumb for quite a large distance. Surely, it would be pretty easy to design a system that hid the player at a distance if that player was proned in grass. The hide level could be altered based on crouch, prone and grass length or density.

Thanks for the reply, I didnt think about using triggers. I'll look into that and post back later. I can see the item that I've placed in the house clearly, basically, its a sensor which is 5 foot tall with a small antenna on top. When placed near an open door where the top half of the sensor is above thre ground level with the outside as the backdrop, the menu appears but if the sensor is placed in the house with the backdrop being a wall, its near impossible to bring up the action menu.

Just bumping this incase. Have been doing more tests on this, the problem seems to be more noticable in different types of buildings. There is a corregated building near the barracs at the NW airfield that is much worse. Placing an addon unit here that has action menus assigned does not work at if all of the unit is in the building. If part of the unit is in a doorway, placing the in game cursor over that area of the unit will display the propper addon menu.

I've built an addon than I have classified as a vehicle so I can add and remove Item actions on the fly in script. The problem I'm having is that if the addon is dropped in a house, Its practcally impossible to access the action menu. Ive noticed that if I drop the item in the doorway of a house and crouch, so that I can see the top of the item and the background is not the house, the action menu appears correctly. Is anyone aware of a workaround for this as its the last problem Ive got with what I'm trying to build.

Excellent, thanks for your help. I'm going crazy on functions at the moment, hoping to build a bit of a tool kit.