Tiskahar

Also it won't release the cursor when it CTDs, so I have to use my keyboard to navigate task manager..

Unfortunately, I agree with OP. There have been a lot of random CTD's in the past two stable branch builds. It's frustrating. Here's ONE of mine: http://feedback.arma3.com/view.php?id=22464 But that being said, developing in Arma always has been and likely always will be a frustrating process with many ups and downs. ---------- Post added at 22:11 ---------- Previous post was at 22:00 ---------- Also, dealing with several of these CTD issues over the past couple weeks.. I'm willing to accept that if I'm developing a mod, I'm running the risk of hitting these issues. My problem is that it is very hard for me to debug the problem. The bidmp file I cannot open, the mdmp file wants access to arma3.exe code, which I don't have. At one point I was dealing with a CTD when I executed a doMove command on a group member that was in a custom formation my team created. Why? Who knows. There is very little documentation on custom formations. Was the logging useful? It gave me a stack_overflow. Thanks. Solution? Don't use doMove command on the units in that formation. OK.. I mean.. sure..

I agree with WarLord's concern, but. You don't need to edit any of his work in order to do what you're looking for. Look into an eventHandler of "hitPart" type. That should tell you if the shot is hitting glass. If it is, set the damage to zero. Done.

Anybody else getting crash to desktop like crazy in this version? Seems everything I do crashes to desktop. _unit doMove _pos; CTD. 30% of the time.

So what do you mean when you say it "doesn't work"? What is it doing? Diag_log out a count on _mines. Is it an empty array? What happens if you bump up the radius? Are you completely positive that there is a mine in the area? Bump up the radius to 50 and then place a mine right next to your player and run it. Zero mines? One thing that comes to my mind right away is the sometimes unexpected behavior of positions. position, which is a synonym for GetPos, is a terrible command and should be avoided. It will give you inaccurate and slow information. Change that to a getPosATL. Also, sometimes commands like these will have issues deciding whether or not the item -actually is- within the radius. That can be determined by a difference in an objects local [0,0,0] position relative to the world and the world positionATL. I've found that I can stand right next to an object and a nearestObjects at 10 meters won't catch it but 15 or 20 will. For something as simple as this, if you find it isn't behaving, use what works [in this case the nearObjects]. The sortBy functions are overblown for your needs. I would do something as simple as: _pos = getPosATL player; //or whatever position you need _dist = 30; _mine = objNull; { _d = _x distance _pos; if (_d < _dist) then { _mine = _x; _dist = _d; }; }forEach _mines; Finally, I don't see why you are using the vectorDistance command for a distance decision. Use distance or distanceSqr (if you're REAAALLLLY pinching pennies).

For me, I would do this with event handlers. On a put event, store player, weapon, location and time information somewhere, whether it be on the holder, a game logic that you spawn, a global variable or publishing it to the server to hold on to. On a take event, check for information related to this weapon wherever you stored it and match them up. You would probably only need to match location and weapon type for it to work, then grab the player information from the rest of the info that you stored. I might even keep a public variable somewhere that has a whole list of these, and every once in a while iterates through and checks to see if the weapon is still around or if a certain amount of time has elapsed as the condition to remove the element from the list. A take event would also remove it from the list.

That's an interesting read, I hadn't seen that before. Thank you for that! I'll have to look up those mods and the ticket. I'm hoping to do fairly extensive rework.

marven, you need to have a separate uniform class for each uniform model and texture set that you have. You must link them with the appropriate soldier model so that the game can compile a new soldier model with the new uniform at load time. As far as I am aware, uniforms work by switching out the units torso model with the one of the new uniform, and uniforms are not 'laid over' the existing torso model.

Nimrod_Z's line is exactly what you are looking for, regardless of the mission or mod you are playing. Replace your while true do block with that line and it will disable fatigue. If you are trying to, say, ease the slope of fatigue, you will need to edit cfgFatigue (I -think-, but I haven't gotten into that brush fire yet) in a mod. I don't think this is what you are attempting to do. init.sqf is not for a mod, it is for a mission. Placing an init.sqf inside a mod folder will do exactly nothing. The init.sqf should go in the folder of your mission before you compile it. Another way to do this would be to enable debug tools on the server or map, hit escape and enter 'player enablefatigue false' into the code box in the menu and hit the middle, 'global execute' button, which will execute that line on every client, thus solving your issue.

For posterity.. formationEntity.fsm is the standard soldier AI that points to hardcoded behavior. This handles peacetime behavior. I haven't played with editing it yet, but it has another version in cfgFSM called simply 'formation'. formationC and formationCDanger are the Civilian scripts. FormationC simply handles path finding for civilians and adds in a little random jitter (path finding is handled by the engine and relayed to a units expectedDestination. This file sets the current destination to the expected destination to ensure the unit follows the path provided to it by the engine). formationCDanger handles the danger reaction for civilians, which includes their decisions to duck, crouch, run away, and investigate bodies. The formationCDanger is, honestly, bad simulation. AI runs -toward- explosions that have killed other units. These files can be edited by the fsm editor, decent documentation found in the VBS Developer documentation (other tools -> FSM editor). They will be indicated in the FSM by the line 'fsmFormation = ' and 'fsmDanger = '. You can then package up your new FSMs and point to them there. Danger.fsm is the danger script used by soldiers. It is also pretty poor simulation and would be a good start for someone looking to make soldiers smarter about how they react in battle. Since setHideBehind and findCover commands no longer work, a user built find cover routine will be necessary, though not entirely difficult if you've done your reading. The difficulty would mainly in getting it to run inexpensively. The magic variable _queue is provided by the engine but I have yet to find good documentation for it. I've not been able to get solid information out of this variable, but occasionally I get good information by logging _dangerCause. _dangerCause appears to be derived from _queue, so I don't know why this is the case, but there it is. The information it provides is an id number for the type of danger (indicated in the fsm as a comment, but not entirely clear ['DCfire' indicates observed bullet impact]), the position of said danger, and, in some cases, the object that produced the danger. It should be noted that very often the danger fsm is fired -without additional information- and thus the unit will enter into a default state as it finds 'no danger' [because there was no id provided], which in most cases is 'do nothing.' As far as the AAR goes, I fixed the function myself, but as it keeps gigantic arrays of information stored in the profileNameSpace, profile files grow extremely large in a very short period of time. This slows down loading and unloading of all aspects of the game to unacceptable levels, which may be why the function is no longer supported.

That's an interesting thought. I discovered that I can get agents to play animations, but if I wanted anything near full movement I would have to go through and write a full movement and pathfinding routine and tie those all to the animations. I think that would be more expensive than its worth. I'm still not completely giving up as this was recommended by a senior BIS programmer, but until they provide more information I'll put it on the back burner. What I've been doing up to this point was spawning and deleting units as players come in and out of range. It can cause a few jitters as I'm spawning in ~100 units at a time, but it keeps the total AI count down. I wonder how enablesimulation false will play in. Thanks, man.

For posterity, I figured this one out. In the original formationC.fsm, there is a loop (roughly 100 hz, if anyone is interested), which checks 'expectedDestination _this', adds in a random distance, and then '_this setDestination's it back in. If you use a 'doMove' command, it seems to set the basic destination, and then hard coded path finding takes over and sends that information to the units 'expectedDestination.' To get the unit to follow the engine derived path finding information, you must use 'setDestination' with the information given by expectedDestination. In this example, I added a condition off my main movement state at low priority with true condition and '_this setDestination (expectedDestination _this)' as the action. There is a link to the condition from the state and right back to the state. The unit moves as desired. I haven't checked how frequently it runs yet, but I will in the future to see if the fsm tick time is a constant value, and if it is, pinpoint that value. Also, contrary to VBS documentation, doMove command does not terminate an Arma FSM. I haven't yet tested it in VBS as my trial has expired.

Hey guys, I'm trying to get units to move via the engine designated formation fsm. In the config file it's defined by fsmFormation. The issue I'm trying to resolve is getting the units to move properly. doMove and moveTo do not result in movement. setDestination causes the units to ignore collision with walls, buildings and all other objects. Does anyone know how to get units to move in this low level environment? would a spawn command get me out of the fsm environment and into something that would allow this to work? ---------- Post added at 20:25 ---------- Previous post was at 20:19 ---------- [_this, _pos] spawn {(_this select 0) doMove (_this select 1)} does not result in movement.

hmm.. That makes sense given what I've seen from the engine, but not the advice I was given. Thanks for the reply.

I'm not sure if this is causing your issue or not but; uniforms are side restricted. I.e. side WEST cannot wear side EAST uniforms, etc. Players are usually exempt from this rule but it can still cause strange issues.