madrussian

Anyone else having spinning (or otherwise glitching) view on IFA3 assembled weapons? (With machine guns like "LIB_MG42_Lafette_low_Deployed", mortars like "LIB_GrWr34", etc) Fortunately, I have some insight and a temporary workaround. So this problem was happening in my dynamic mission, where these weapons come as the parts (tripod and weapon) in crates, to be assembled by the players. Upon assembling the weapons and mounting them, players would always get spinning view. Disembarking weapon and getting back on unfortunately does NOT clear the problem, resulting in the same issue. After a bunch of testing, I learned the following: The issue seems to only occur with spawned vehicles (created via createVehicle, which is exactly what happens when the player assembles them). When placed in the Editor, the vehicles are fine. The issue occurs with only the first instance of the vehicle. So the workaround is to simply create a dummy instance of the vehicle (out in the middle of nowhere) and then immediately delete it first. Then allow the player to assemble it or spawn it whole (per your particular mission design). When players then mount up, the "spinning view" issue has already been eliminated. It's not quite that simple, as some of these weapons may be raised or lowered, and so you must account for both vehicle types, as the spinning view will occur on the first instance of each type. So for example, to remedy spinning view on Wehrmacht MG42, you must create dummy instances of both "LIB_MG42_Lafette_Deployed" and "LIB_MG42_Lafette_low_Deployed". And then do the same for any other weapon platforms you intend to spawn (or for which you provide the required parts for players to assemble). Hope that helps someone with eliminating this "spinning view" problem, which vexed me for ages.

Just wanted to stop by and say how much I appreciate your mod. Simply awesome, please keep going! For those experiencing English speaking Germans when playing with FOW (or English speaking Russians when playing with FOW + IFA3) and who may be unaware, this is an issue with FOW mod overwriting voices of various units (affecting both FOW and non-FOW units). Thankfully it appears the FOW team is currently working on this. In the mean time... I wrote a temporary script based fix for this FOW voice issue that's working well for me so far, restoring all unit voices to proper state (works well in SP and MP). Feel free to use my voice remedy (which you can find here) until FOW team puts out a proper fix. Hope this helps out, cheers.

Opps, this is actually a FOW issue. My limited testing reveals that FOW is overwriting speaker to empty string on various units (including IFA3 and vanilla units too), which results in default game voice (which is English speaking). I did a bit of searching and found that this was indeed acknowledged by Giallustio here on 4/24/18. So, nothing to do with IFA3...

I was having "vehicle engine won't start" issue too. Found this thread and discovered my problem was indeed flooded engines. (Thanks das attorney!) Adjusted my spawn points to ensure 100% they were above water. Low and behold, shocked to discover I was still getting flooded engines. Turns out selecting the right spawn point (above water factoring in AGL vs ASL, etc), is only half the battle. You must also use the correct form of the createVehicle command. The original createVehicle syntax will ignore the Z component of your spawn position and place the newly created vehicle on the surface of the land at that position (... even if that's under water!): _vehic = "B_G_Offroad_01_F" createVehicle _spawnPos; Using the extended syntax with "CAN_COLLIDE" overcomes this phenomenon, placing the vehicle exactly at your provided spawn position: _vehic = createVehicle ["B_G_Offroad_01_F", _spawnPos, [], 0, "CAN_COLLIDE"]; Once I made this syntax switch, no more flooded engines. (Btw - Also wanted to point out that the flooded engine thing happens instantaneously. Even if you create the vehicle underwater and teleport it to land all inside called code so that literally ZERO time elapses, it will still flood your engine.)

To all those involved, thanks again for your dedication and hard work. Simply amazed by what you've achieved so far, can't wait to see what's next. Couple quick questions: Anyone know why the command speaker returns an empty string for IFA3 Russians and Germans? (Turns out that’s playing havoc with my group-linked respawn script. Also, interestingly speaker does return the valid speaker for IFA3 United States units.) Also, any insight on whether players (on foot) loading IFA3 mortars works for anyone? Or is it bugged currently? (That’s one of the final items holding up release of my blockbuster dynamic mission, tailored for WW2 and which I believe many of you will quite enjoy.)

In-line ASDF here (D forward, S back). G and V to change stance. Z to look around.

Quick question regarding IFA3 mortars: How is the player suppose to load them? Take the M2 60mm for example, which I place into the editor (simple test mission). I walk up and it has several actions available: “Load”, “Prep 60mm HE rounds”, “Prep 60mm smoke rounds”, “Unload ammo from M2”, and then the usual get in and disassemble actions. When I get in I see it has 2 mags of 8 rounds each. Unloading via action functions as expected, unloading 1 magazine each time, to player’s inventory (which I checked and saw in there). However, when I try to load it up again by first prepping ammo via either “Prep 60mm HE rounds” or “Prep 60mm smoke rounds” (to make that action turn from red to green) then do “Load” action, nothing seems to happen. Plus if the mortar is empty, the load action gives a hint saying simply “No ammo prepared” or "No ammo", even though I’m holding the mortar rounds I unloaded moments before. I was able to comprehend and operate the load/unload for assembled MGs successfully, so hopefully I’m just missing something simple? (In my dynamic mission, mortars and MGs come in a supply drop, and must be assembled. As the mortars start out empty upon assembly, I also put some mortar ammo in the supply drop crate for the player to load them with.)

@.kju Lol, thanks that sorted it!

Anyone know which command(s) are used to disable speech / radio by default with IFA3 foot units? Reason I ask - In my mission, I need one particular unit to say something via sideChat (in this case reporting he successfully delivered supplies to base). I'd like to re-enable sideChat (along with possibly radio, etc) for this one guy.

While on the subject of disembarking... Quick thing that always bugged me. @oukej, maybe you can kill two birds with one stone. Embarking units can be killed while attempting to embark, which is fun for the player (and makes sense): However, currently disembarking units are invulnerable, which doesn't make much sense, and isn't much fun: Surely, it's possible to make these disembarking guys vulnerable too? Please correct if I'm wrong. I played around with PhysX engine long ago, and if I recall correctly, one-way collision detection was possible. For instance, it should be possible to have dead or unconscious foot units take collision from the truck, but have the truck take no collision from the dead or unconscious guys. Translation = Enabling foot unit vulnerability while disembarking should be totally possible, without danger of the truck going flying? Thanks again for all your efforts.

Wow, good catch! I just checked it. Four NATO riflemen in editor, one as player, none as captive. Killed two men and checked player's rating and side. Player's rating was -2000 and side was still west. (As memory serves, -2000 always resulted in sideEnemy before.) Shot 3rd man, checked player again. Rating was -3000, side was sideEnemy. Looks like perhaps the bar got moved down? Looks like you can kill 2 basic friendlies now without penalty. Edit: Ran the above test in SP.

Good observation. In Attributes->General, set west and resistance to be enemies of one another. In player init field, set player as captive. Plus, in each AAF squad leader's init field: { _x assignAsCargo truck1; _x moveInCargo truck1 } foreach (units (group this)); ...for each squad/truck.

Found a very bad vanilla bug when the AI disembark (related to driving): Vanilla ArmA 3, version 1.82.144710. 100% repeatable. Shoot the AI to get them to disembark. Guy getting out will errantly collide with vehicle, often causing vehicles to completely flip over. Worst offenders are guys getting out of the front, but guys getting out of back can cause very high impact collisions too, if you experiment long enough. Wrote it up here: https://feedback.bistudio.com/T129131 I think I started noticing this alongside the Tanks DLC platform updates. I like that vehicle to foot unit collisions now seems to be better & seem to last for longer. I'm hoping devs can keep all that great new collision/interaction! Just fix the automatic high-impact (game-breaking) collision where AI is disembarking (and conscious, etc). Btw - This issue is happening with a lot of different vehicle types, including mods when mods are loaded. (Also should re-iterate, video above is unmodded game.)

@Larrow and fn_Quiksilver: Thanks for responding, all good points! I can confirm the falling radial blur is not inside BIS_fnc_feedbackInit. I tried a robust scan of missionNamespace, uiNamespace, and player variables, like this: First in SP editor: Place two men, make one the player, and name the other one Loon. Then run this code: My scan correctly detects current PP effects. Once falling, scan shows falling radial blur PP. Once you become the new guy, if you start running a second current PP effect is detected, and that 2nd one goes away when you stop running. Unfortunately, variable detector gets no hits for the falling radial blur. Thus, it appears falling radial blur is not stored in missionNamespace, uiNamespace, or on player (as numbers or numbers inside arrays). Anyone know where else to look? Perhaps falling radial blur is (only) being stored internally by the engine? If so, maybe BIS can give us this handle via a variable? All those other blurs have a variable, why not this one too? Alternately, if BIS could give us a new command to detect what type of PP effect a give handle is, that would work well enough to detect and shut it off (which beats what is possible currently with shotgun disable approach and always getting a script error). Something like ppEffectType?

There's a PostProcess effect I need to remove for my Respawn system to work properly. It's the radial blur you get while falling (from height over 100 meters to ground). It's definitely a "RadialBlur", as going to Video Options and turning RADIAL BLUR off and on hides it and shows it. Anyhow I absolutely need to hide it, and via script. (Without hiding this "RadialBlur", upon respawn the player is stuck looking at it!) I can successfully disable this falling "RadialBlur", using a shotgun approach: for "_i" from 0 to 1000 do { if (ppEffectEnabled _i) then { _i ppEffectEnable false; _i ppEffectCommit 0; }; }; This is far from ideal of course, as it disables all PP effects. Obviously, a more targeted approach is necessary. I can successfully hide this falling "RadialBlur" via ppEffectAdjust: for "_i" from 0 to 1000 do { _i ppEffectAdjust [0,0,0,0]; _i ppEffectCommit 0; }; This targets all "RadialBlur" and leaves all other PPs alone. But this gives script errors, which makes sense as ppEffectAdjust accepts different number of settings based on what type of PP effect you are adjusting, and there are always multiple PP effects running (in default game), some of which are not "RadialBlur". Unfortunately I don't see any script command that tells what type a given PP handle is. Apparently, what I need here is the actual handle for the falling "RadialBlur" PostProcess effect. Anyone know how to obtain it? Or other ideas on targeted ways to disable this troublesome PP "RadialBlur" effect?

(Not sure if this is correct place to post but I hope it gets fixed. Thanks!) 100% repeatable. Game v1.80143869 with no mods loaded. Here are quick steps to repeat: [Two players, hosted server] 1. Open the editor, place two playable units, one with a large full backpack and one without. (Use “B_Soldier_A_F” and “B_Soldier_F”.) 2. Place two trucks (use “I_G_Offroad_01_F”). Name trucks “truck1” and “truck2”. 3. Clear the cargo from both trucks and add a small empty backpack to both trucks, like this (in "init.sqf"): 4. Fill the 2nd truck with cargo to at or near capacity, like this (in "init.sqf"): 5. Start game, have both players approach truck1 (the empty truck, empty except for its 1 small backpack inside). 6. Have player #1 put his large camo backpack in the truck and take it back out. Have player #2 take the small black backpack from the truck and put it back in. This shows backpacks are functioning normally. [Disregard truck1 (along with it's 1 small backpack inside) from this point onward.] 7. Have both players approach truck2 (the full cargo truck, which also holds 1 small backpack inside). Ensure player #1 is still holding large camo backpack. 8. Have player #1 open the truck’s inventory, and right click on his large camo backpack in an attempt to put it into the truck. Note that nothing happens, as the truck is full and the backpack won’t fit. (Everything is operating correctly so far.) 9. Now, with player #1 still having truck’s inventory up, have player #1 right click on the small black backpack from the truck’s inventory (to take it). 10. Note that the game knew that player #1's large camo backpack wouldn’t fit in the truck, and thus automatically placed large camo backpack on the ground, to make space for small black backpack in player #1’s inventory. Also note that player #1 is now holding small black backpack. (All of this so far is operating correctly.) Here’s the problem: Notice there are now actually TWO small black backpacks: One that correctly appears in the player #1’s inventory, plus an erroneous duplicate (seen in the truck’s inventory). 11. Have player #2 pick up the erroneous duplicated black backpack from the truck. Now quantum entanglement is apparent, as both player’s are wearing the “same” small black backpack and both player’s machines continuously update the position/orientation of the backpack. (Basically both players can see both backpacks jumping up and down on each player model, especially noticeable if one player kneels down or similar.) 12. If player #1 drops the backpack by picking up his original large camo backpack, player #2’s model stretches (in unbelievable fashion, visible on both machines). When both players drop and abandon the entangled backpack, player models return to normal, but the entangled backpacks remain bugged (and can’t be used properly anymore due to entanglement). Btw- I checked and the backpack duplication part (when truck cargo full or near full) occurs in SP also. Hopefully that extra bit will help while tracking it down. In any event, hope this all helps (and gets fixed), thanks!

OK, I submitted a report on the tracker here. Here's more info from the report, for anyone curious: Bug Description (bit more concise): With a backpack on your back, taking a backpack from a full (or near full) vehicle or crate results in a bugged duplicate backpack (SP and MP). If another player picks up the bugged duplicate backpack, both players see glitchy jumping backpacks. (MP) If original player then drops backpack, both players see 2nd player model stretch into bizarre pattern. (MP) Additional Information Please also note, this is not only a case of a vehicle/crate starting out over-filled. This also occurs when the vehicle is *near* full. It happens when the space taken by your originally-held backpack plus the taken space in the vehicle exceeds the capacity of the vehicle, when you attempt to take a backpack from the vehicle. In this case your original backpack is automatically placed on the ground (correctly). So in the case of almost-filled vehicle, the bug still happens even though at no point does the vehicle actually over-fill.

@kju, hope you feel better. Interested to hear what you discover, good luck with your search. (Btw- I tried to duplicate this with various multiturreted tanks, and only the LIB ones appear to be ejecting crew like this.)

OK, this is really strange. Please correct me if I'm wrong, but I seem to have characterized a major problem with tank turret gunners always disembarking when they should not. Here is a very concise "steps to repeat": 1. First, place a crewed LIB tank in the editor. For simplicity use “LIB_PzKpfwV”. Note that it has 3 crew by default (driver, gunner, commander). Note also it has two extra turret positions (for a total of 5 non-cargo positions). 2. Add a couple extra crew to the tank (added to crew's original group), like this: 3. Place a same sided man (it can be a default man or even a default vehicle) close to the LIB tank. I used “B_Soldier_F”. 4. Place player foot unit (of opposite side as LIB tank), behind the LIB tank and man. Do a “player allowDamage false” on yourself so you can observe without being killed. 5. Start the mission. Simply shoot the other man. (I shot him with pistol once and did not kill him.) Immediately, LIB tank’s 2 extra gunners bail out! Obviously, this should not happen. (Similar multi-turreted vehicles from other mods do not eject their crew members in this manner.) Note the original 3 crewmen stay inside the tank. 6. To further pin down the issue, run the test again but first disableAI “ALL” on all 5 of the LIB tank’s crew members. Upon shooting the man, the 2 extra turret gunners will still bail out (even though no one in the crew has any AI running). If this can be resolved, maybe at some point we can get fully crewed tanks in the editor? (If so, that would be awesome!) In any event, hope this helps out.

Quickly wanted to say, thanks guys for all your hard work. It's simply amazing what you've managed to achieve so far. Any insight on how to get LIB tank turret gunners (with turretPaths other than driver, gunner, & commander) to stay in the tanks? They keep disembarking when tank is hit by small arms gunfire. I tried numerous things, all detailed here: UPDATE (updated spoiler too) - So I looked through some of the LIB scripts and there are a few places where it appears doGetOut and moveOut are called. You all may want to look into those and also search the code for any related commands (allowGetIn, orderGetIn, etc) as it seems those calls are not accounting specifically for (non driver, gunner, and commander) turret gunners.

I'm very impressed with the recent AI Driving update, driving is indeed much improved! (obviously still needing some tweaking) I was hoping the "path-finding" update would fix another longstanding issue, but with foot soldiers. AI building path-finding in ArmA has always been a mixed bag. Just talking about open buildings here, those with positions detectable via buildingPos. Also, focus of this thread is not about open buildings on Tanoa or lack thereof, rather AI getting into and out of open buildings (partially open or otherwise). In my experience, AI building path-finding falls into 3 categories: On the one hand, most of the time AI can successfully enter & exit these buildings (via doMove to buildingPos), which is awesome! In many cases, AI cannot enter certain open buildings in the first place. The path-finding is busted. This seems to be an issue where the building model itself is fine (duplicates of the building elsewhere on the map work just fine), but perhaps this instance of the building was placed poorly on the map (door slightly too high from terrain, building hemmed in too close with other buildings and/or objects, etc.) Although disappointing, it's not a terrible problem. Next item however, is a real deal-breaker! In many cases, AI can enter the open building reliably just fine (via doMove to buildingPos), but gets absolutely stuck inside. When stuck like this, AI can travel between the building positions just fine, but here's the kicker: The AI can never leave the building, he is forever stuck inside. (Barring teleportation via script, lining him up at the front door and doing a forced animation, etc). This "able to enter / unable to leave" issue occurs even with a single man in a group, even with no other men in or near the building, unit not in Combat, etc. This is a true path-finding problem, and it's terrible for building takeover scripts. Also, there is no way to detect these "trap" buildings via script to avoid them (without going to super-extraordinary lengths, such as automated overnight tests where you spawn a man in each building position on the map, ordering him to leave the buildings repeatedly, and collecting the results to form a mega "banned buildings" list, and doing this over and over again per map). I dream of a day when we can script reliable AI building entry/exit. I personally picture an MG-42 team on a Stalingrad type map moving from one partially destroyed building to another, setting up MG positions from the windows. Seems to me, the first step towards this lofty goal is making sure the AI can reliably leave a building once it enters. After seeing the radical improvements to AI Driving, I'm very hopeful for a solution in this area. Any plans for improved AI building entry/exit navigation?

I'm curious about this also.

Hopefully this should be a no-brainer, but I’m quite stuck atm. I need to assemble a list of all owner IDs (or any type of IDs) for all machines in a MP game. The trick is, my code is operating in Pre-Init space (as in, prior to “init.sqf” kicking off), via (added to "description.ext" per CBA documentation): class Extended_PreInit_EventHandlers { BubMission = call compile preprocessFile "XEH_preInit.sqf"; }; Why punish myself and attempt to tackle Pre-Init space? I’ve worked out how to get all this (see spoiler) working in the unscheduled environment of Pre-Init, except for one key detail: I need to assemble a list of all owner IDs on the server (or even a simple machine count), so I know when all the clients are done reporting in. The trouble is, in Pre-Init, there are no units yet. In other words, in PreInit the allUnits command returns an empty array (which btw strikes me as rather awesome… don’t you think? A world with no units, vehicles, and for that matter no insects, devoid of… well anything. Also time stands still, as in time command continuously returns 0. Ha, Arma’s Twilight Zone!) Normally, you can generally just spin through allUnits (and check isPlayer) to count the number of machines. This obviously won't work here, again due to no units. Turns out in Pre-Init space, remoteExecCall works great, so I can have all Clients report and count them on the Server. The trouble is, without a machine count I have no idea if any particular Client reporting in is the last one, or if more are coming. Any way to count “players” before they embody units? Or count the number of “players” signed into your game? (The game must know all player info in MP even at this stage, obviously because it has to transmit the mission to the Client machines, etc.) Anyone have any insight? It occurs to me there must be a way. Thanks for reading.

So, I was reluctant to uncheck Enable AI because my entire mission revolves around player-led AI groups. However, the initial “lobby” units in my mission are actually just placeholders anyway, and each player has selectPlayer called on his machine for player to embody his first real playable unit (which happens after the config scan, faction selection check, etc). All the initial placeholder guys get deleted quickly anyway. Long story short, yes for my particular mission playerNumbers will work! Having to uncheck "Enable AI" in not ideal though. When I open any MP mission I quickly notice one of two things: Grey “Nobody” in all the slots - This typically indicates a player-only MP game, probably with revive, and most likely with absolutely no AI in the player groups. (I quickly close these missions because I prefer traditional co-op) Red “AI” in all the slots - This typically indicates traditional co-op, AI will fill out the slots, possibly group-respawn. I also assume that if I’m the only one playing, I should pick first unit so I can lead the AI group. (This is my type of game and I continue and check it out!) So at the moment I am stuck making a mission that’s all about players leading groups of AI, but upon opening the mission it will appear to players to be a player-only MP game (due to all those grey “Nobody”s). Imo, would be nice to have a command that simply counts connected machines! Or an alternative syntax for playersNumber, that provides count of player-occupied slots only (instead of counting player & AI occupied slots). Anyhow, thanks again for the help… I can proceed. In the mean time, if anyone knows a way to count machines in PreInit space (and keep "Enable AI" checked), I'm all ears.

I did something similar a while back. An objective where you have to destroy a fuel truck, but the default fuel truck explosion is pretty weak and just pretty much fizzles. I wanted the truck to really go BOOM! So I added a killed EH to fuel truck, and upon destroyed I spawned and detonated a large bomb (the huge one the Wipeout drops). Worked great, huge boom indeed!!! But... it was killing everyone in sight, including the player and his squad nearly that destroyed the truck. After some experimentation, I came up with the perfect solution. I attached the bomb inside the truck using attachTo (completely encased with no part of the bomb showing) and then detonated the bomb. Finally, everything was perfect. BIG BOOM visual effect! (that deals zero damage) Plus small boom that still killed people close by in limited way (due to the original truck explosion). In short, maybe you could encase your bomb in slightly larger object that will (completely) shield the blast.